mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-21 08:29:39 +08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
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.
This commit is contained in:
Tom Lane 2011-06-02 15:31:02 -04:00
parent c117838597
commit bc0550f994
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/backend/commands/sequence.c
View File

@ -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.
* If we see this has happened, clean up after it. We treat this like a
* hint bit update, ie, don't bother to WAL-log it, since we can certainly
* do this again if the update gets lost.
*/
if (HeapTupleHeaderGetXmax(tuple.t_data) != InvalidTransactionId)
{
HeapTupleHeaderSetXmax(tuple.t_data, InvalidTransactionId);
tuple.t_data->t_infomask &= ~HEAP_XMAX_COMMITTED;
tuple.t_data->t_infomask |= HEAP_XMAX_INVALID;
SetBufferCommitInfoNeedsSave(*buf);
}
seq = (Form_pg_sequence) GETSTRUCT(&tuple);
/* this is a handy place to update our copy of the increment */