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

From Heikki Linnakangas
Subject Re: Hot Standby dev build (v8)
Date
Msg-id 49745463.3020300@enterprisedb.com
Whole thread Raw
In response to Re: Hot Standby dev build (v8)  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Hot Standby dev build (v8)  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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

> But I can't see how there can be one: Two concurrent vacuums can have
> different OldestXmin values, but two concurrent transactions cannot.

Of course they can.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby dev build (v8)
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby dev build (v8)