Re: Hot Standby dev build (v8) - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Hot Standby dev build (v8)
Date
Msg-id 1232363695.2327.34.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Hot Standby dev build (v8)  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Hot Standby dev build (v8)
List pgsql-hackers
On Mon, 2009-01-19 at 12:50 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > One of us needs a coffee.
> 
> Clearly, I put the kettle on...

I had one too, just in case.

> > How does Transaction 4 have a RecentGlobalXmin of 2 in step (7), but at
> > step (9) the value of RecentGlobalXmin has gone backwards?
> 
> Looks like I mixed up the xids of the two transactions in steps 8 and 9. 
> Let's see if I got it right this time:
> 
> 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 4 kills tuple, using its RecentGlobalxmin of 2
> 9. Transaction 3 splits the page, emits a delete xlog record, setting 
> latestRemovedXid to its RecentGlobalXmin of 1

I don't see how step (5) is possible. GetSnapshotData() sets
RecentGlobalXmin to the result of the snapshot's xmin.

If step (5) is possible, then yes, step (9) can happen.

You are correct to say that RecentGlobalXmin is not always correctly
set. All I'm saying is that at the exact time, place and circumstance I
use it, it is correct. In other cases, it may not be.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby dev build (v8)
Next
From: Heikki Linnakangas
Date:
Subject: Re: Hot Standby dev build (v8)