git.postgresql.org Git - postgresql.git/commitdiff

git projects / postgresql.git / commitdiff

Clean up after erroneous SELECT FOR UPDATE/SHARE on a sequence.

Thu, 2 Jun 2011 19:31:02 +0000 (15:31 -0400)

My previous commit disallowed this operation, but did nothing about
cleaning up the damage if one had already been done. With the operation
disallowed, it's okay to just forcibly clear xmax in a sequence's tuple,
since any value seen there could not represent a live transaction's lock.
So, any sequence-specific operation will repair the problem automatically,
whether or not the user has already seen "could not access status of
transaction" failures.

src/backend/commands/sequence.c patch | blob | blame | history

diff --git a/src/backend/commands/sequence.c b/src/backend/commands/sequence.c

index 292a427449321bd4bb282ca3f56b5816b6799a80..adeb0d52d48f56bbcf55eaadf8c267983696b64f 100644 (file)

--- a/src/backend/commands/sequence.c

+++ b/src/backend/commands/sequence.c

@@ -982,6 +982,22 @@ read_info(SeqTable elm, Relation rel, Buffer *buf)

Assert(ItemIdIsNormal(lp));

tuple.t_data = (HeapTupleHeader) PageGetItem(page, lp);

+ /*

+ * Previous releases of Postgres neglected to prevent SELECT FOR UPDATE

+ * on a sequence, which would leave a non-frozen XID in the sequence

+ * tuple's xmax, which eventually leads to clog access failures or worse.