On Wed, 2011-10-26 at 12:19 -0400, Robert Haas wrote: > > 1. In session A: BEGIN; SELECT * FROM foo WHERE id = 1; COMMIT; > > The row has xmin = 123456, and it is cached as committed in the one-item > > cache by TransactionLogFetch. > > 2. A lot of time passes. Everything is frozen, and XID wrap-around happens. > > (Session A is idle but not in a transaction, so it doesn't inhibit > > freezing.) > > 3. In session B: BEGIN: INSERT INTO foo (id) VALUES (2); ROLLBACK; > > By coincidence, this transaction was assigned XID 123456. > > 4. In session A: SELECT * FROM foo WHERE id = 2; > > The one-item cache still says that 123456 committed, so we return the > > tuple inserted by the aborted transaction. Oops.
Yes, that's the scenario I was talking about. > Oh, hmm. That sucks. It didn't seem like a major concern a while ago: http://archives.postgresql.org/message-id/28107.1291264...@sss.pgh.pa.us Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
