Skip to content

Commit 24561b4

Browse files
committed
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 344d62f introduced unlogged sequences. Reviewed (in an earlier version) by Robert Haas. Discussion: https://postgr.es/m/20240611024525.9f.nmisch@google.com
1 parent f054443 commit 24561b4

File tree

1 file changed

+7
-0
lines changed

1 file changed

+7
-0
lines changed

src/backend/commands/sequence.c

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -558,6 +558,13 @@ SequenceChangePersistence(Oid relid, char newrelpersistence)
558558
Buffer buf;
559559
HeapTupleData seqdatatuple;
560560

561+
/*
562+
* ALTER SEQUENCE acquires this lock earlier. If we're processing an
563+
* owned sequence for ALTER TABLE, lock now. Without the lock, we'd
564+
* discard increments from nextval() calls (in other sessions) between
565+
* this function's buffer unlock and this transaction's commit.
566+
*/
567+
LockRelationOid(relid, AccessExclusiveLock);
561568
init_sequence(relid, &elm, &seqrel);
562569

563570
/* check the comment above nextval_internal()'s equivalent call. */

0 commit comments

Comments
 (0)