summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndres Freund2023-04-04 23:38:06 +0000
committerAndres Freund2023-04-04 23:42:52 +0000
commit3f695b31179b94a5eaa284ff588a983ff2dce932 (patch)
treefcbf5a16eb674556784b0be514c2be8d3e19a02c
parente126d817c7af989c47366b0e344ee83d761f334a (diff)
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 e8647c45d66a. Given the low risk, it does not seem worth backpatching the fix. Discussion: https://postgr.es/m/[email protected]
-rw-r--r--src/backend/commands/sequence.c4
1 files changed, 1 insertions, 3 deletions
diff --git a/src/backend/commands/sequence.c b/src/backend/commands/sequence.c
index bfe279cddf..f3d1779655 100644
--- a/src/backend/commands/sequence.c
+++ b/src/backend/commands/sequence.c
@@ -377,7 +377,7 @@ fill_seq_fork_with_data(Relation rel, HeapTuple tuple, ForkNumber forkNum)
/* Initialize first page of relation with special magic number */
- buf = ReadBufferExtended(rel, forkNum, P_NEW, RBM_NORMAL, NULL);
+ buf = ReadBufferExtended(rel, forkNum, P_NEW, RBM_ZERO_AND_LOCK, NULL);
Assert(BufferGetBlockNumber(buf) == 0);
page = BufferGetPage(buf);
@@ -388,8 +388,6 @@ fill_seq_fork_with_data(Relation rel, HeapTuple tuple, ForkNumber forkNum)
/* Now insert sequence tuple */
- LockBuffer(buf, BUFFER_LOCK_EXCLUSIVE);
-
/*
* Since VACUUM does not process sequences, we have to force the tuple to
* have xmin = FrozenTransactionId now. Otherwise it would become