On Wed, Jan 5, 2011 at 3:06 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote: >> >>> > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong; >>> > what I have now is better, but your point is there may be an even better >>> > truth. I'll think on that a little more. >> >> I remember that I thought some more on this and decided that I couldn't >> see a problem. I also see I didn't update the list to say that. >> >>> I guess the problem case here is something like: >>> >>> 1. T1 begins. T1 writes a tuple A (so it gets an XID). >>> 2. T2 begins. T2 writes a tuple B (so it gets a later XID). >>> 3. T1 takes a new snapshot that can see B and deletes B. >>> 4. T2 commits. >>> 5. T1 commits. >> >> How is step (3) possible before step (4)? > > At read committed isolation level, which is the default, we take a new > snapshot after every command.
Oh, I'm a dork. You're saying T2 hasn't committed yet. Let me think about this some more... -- 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
