Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> 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.
I think this is probably a red herring, because it's impossible for a
session to remain totally idle for that long --- see sinval updating.
(If you wanted to be really sure, we could have sinval reset clear
the TransactionLogFetch cache, but I doubt it's worth the trouble.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
