On Wed, Oct 26, 2011 at 11:52 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 26.10.2011 18:42, Robert Haas wrote: >> >> On Tue, Oct 25, 2011 at 12:37 PM, Jeff Davis<pg...@j-davis.com> wrote: >>> >>> Aren't there a few other cases like this floating around the code? I >>> know the single-xid cache is potentially vulnerable to xid wraparound >>> for the same reason. >> >> I believe that we're in trouble with XIDs as soon as you have two >> active XIDs that are separated by a billion, ... > > That's not what Jeff is referring to here, though (correct me if I'm wrong). > He's talking about the one-item cache in TransactionIdLogFetch(). You don't > need need long-running transactions for that to get confused. Specifically, > this could happen: > > 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.
Oh, hmm. That sucks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
