Re: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records
От | Robert Haas |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records |
Дата | |
Msg-id | AANLkTimKVVeH3Lu7Ar=mG4e+KzSvuxFeuRpn1UJu84fh@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Reduce spurious Hot Standby conflicts from never-visible records (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Wed, Jan 5, 2011 at 3:06 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs <simon@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
В списке pgsql-hackers по дате отправления: