Skip to content

Commit dee60ea

Browse files
anarazelpull[bot]
authored andcommitted
sequences: Lock buffer before initializing page
fill_seq_fork_with_data(), used to initialize a new sequence relation, only locked the buffer after calling PageInit(), even though PageInit() modifies page contents. This is unlikely to cause real-world issues, as the relation is exclusively locked at that point, and the buffer not yet marked dirty, so other processes should not access the buffer. This issue looks to have been present since the introduction of sequences in e8647c4. Given the low risk, it does not seem worth backpatching the fix. Discussion: https://postgr.es/m/20230404185501.wdkmo3k7bedlx6qk@awork3.anarazel.de
1 parent f25b70e commit dee60ea

File tree

1 file changed

+1
-3
lines changed

1 file changed

+1
-3
lines changed

src/backend/commands/sequence.c

Lines changed: 1 addition & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -377,7 +377,7 @@ fill_seq_fork_with_data(Relation rel, HeapTuple tuple, ForkNumber forkNum)
377377

378378
/* Initialize first page of relation with special magic number */
379379

380-
buf = ReadBufferExtended(rel, forkNum, P_NEW, RBM_NORMAL, NULL);
380+
buf = ReadBufferExtended(rel, forkNum, P_NEW, RBM_ZERO_AND_LOCK, NULL);
381381
Assert(BufferGetBlockNumber(buf) == 0);
382382

383383
page = BufferGetPage(buf);
@@ -388,8 +388,6 @@ fill_seq_fork_with_data(Relation rel, HeapTuple tuple, ForkNumber forkNum)
388388

389389
/* Now insert sequence tuple */
390390

391-
LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
392-
393391
/*
394392
* Since VACUUM does not process sequences, we have to force the tuple to
395393
* have xmin = FrozenTransactionId now. Otherwise it would become

0 commit comments

Comments
 (0)