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:
In response to
pgsql-hackers by date
|Next:||From: Magnus Hagander||Date: 2011-10-26 16:47:31|
|Subject: Re: pgsql_fdw, FDW for PostgreSQL server|
|Previous:||From: Alvaro Herrera||Date: 2011-10-26 16:31:43|
|Subject: Re: Range Types - typo + NULL string constructor|