Lock owned sequences during ALTER TABLE SET { LOGGED | UNLOGGED }.

These commands already make the persistence of owned sequences follow
owned table persistence changes.  They didn't lock those sequences.
They lost the effect of nextval() calls that other sessions make after
the ALTER TABLE command, before the ALTER TABLE transaction commits.
Fix by acquiring the same lock that ALTER SEQUENCE SET { LOGGED |
UNLOGGED } acquires.  This might cause more deadlocks.  Back-patch to
v15, where commit 344d62fb9a introduced
unlogged sequences.

Reviewed (in an earlier version) by Robert Haas.

Discussion: https://postgr.es/m/20240611024525.9f.nmisch@google.com
This commit is contained in:
Noah Misch 2024-06-27 19:21:05 -07:00
parent d5f788b41d
commit f88cdb36c4
1 changed files with 7 additions and 0 deletions

View File

@ -545,6 +545,13 @@ SequenceChangePersistence(Oid relid, char newrelpersistence)
Buffer buf;
HeapTupleData seqdatatuple;
/*
* ALTER SEQUENCE acquires this lock earlier. If we're processing an
* owned sequence for ALTER TABLE, lock now. Without the lock, we'd
* discard increments from nextval() calls (in other sessions) between
* this function's buffer unlock and this transaction's commit.
*/
LockRelationOid(relid, AccessExclusiveLock);
init_sequence(relid, &elm, &seqrel);
/* check the comment above nextval_internal()'s equivalent call. */