From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby dev build (v8) |
Date: | 2009-01-19 10:45:52 |
Message-ID: | 1232361952.2327.29.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2009-01-19 at 12:22 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Well, steps 7 and 8 don't make sense.
> >
> > Your earlier comment was that it was possible for a WAL record to be
> > written with a RecentGlobalXmin that was lower than other backends
> > values. In step 9 the RecentGlobalXmin is *not* lower than any other
> > backend, it is the same.
> >
> > So if there is a proof, this isn't it.
>
> Yeah, you're right. I got steps 8 and 9 mixed. Let me try again:
>
> 1. Transaction 1 begins in backend A
> 2. Transaction 2 begins in backend B, xmin = 1
> 3. Transaction 1 ends
> 4. Transaction 3 begins in backend C, xmin = 2
> 5. Backend C gets snapshot, TransactionXmin = 2, RecentGlobalXmin = 1
> 6. Transaction 2 ends.
> 7. Transaction 4 begins in backend A, gets snapshot TransactionXmin = 2,
> RecentGlobalXmin = 2
> 8. Transaction 3 kills tuple, using its RecentGlobalxmin of 2
> 9. Transaction 4 splits the page, emits a delete xlog record, setting
> latestRemovedXid to its RecentGlobalXmin of 1
One of us needs a coffee.
How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at
step (9) the value of RecentGlobalXmin has gone backwards?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2009-01-19 10:50:47 | Re: Hot Standby dev build (v8) |
Previous Message | Heikki Linnakangas | 2009-01-19 10:22:27 | Re: Hot Standby dev build (v8) |