pgsql: SSI has a race condition, where the order of commit sequence num

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: SSI has a race condition, where the order of commit sequence num
Date: 2011-07-07 20:29:56
Message-ID: E1QevCu-0001QA-Gz@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

SSI has a race condition, where the order of commit sequence numbers of
transactions might not match the order the work done in those transactions
become visible to others. The logic in SSI, however, assumed that it does.
Fix that by having two sequence numbers for each serializable transaction,
one taken before a transaction becomes visible to others, and one after it.
This is easier than trying to make the the transition totally atomic, which
would require holding ProcArrayLock and SerializableXactHashLock at the same
time. By using prepareSeqNo instead of commitSeqNo in a few places where
commit sequence numbers are compared, we can make those comparisons err on
the safe side when we don't know for sure which committed first.

Per analysis by Kevin Grittner and Dan Ports, but this approach to fix it
is different from the original patch.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/406d61835b97a801807913e0fc67eadd9c6a3ffa

Modified Files
--------------
src/backend/storage/lmgr/predicate.c | 29 +++++++++++------------------
src/include/storage/predicate_internals.h | 21 +++++++++++++++++++--
2 files changed, 30 insertions(+), 20 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2011-07-07 20:35:09 pgsql: SSI has a race condition, where the order of commit sequence num
Previous Message Peter Eisentraut 2011-07-07 19:55:42 pgsql: Fix use of unportable %m format