Excerpts from Robert Haas's message of mié oct 26 13:19:47 -0300 2011: > On Wed, Oct 26, 2011 at 11:52 AM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> 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. > > Oh, hmm. That sucks. Can this be solved by simple application of the Xid epoch? -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
