Re: HOT documentation README - Mailing list pgsql-patches

From Tom Lane
Subject Re: HOT documentation README
Date
Msg-id 23910.1189615921@sss.pgh.pa.us
Whole thread Raw
In response to Re: HOT documentation README  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Responses Re: HOT documentation README  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-patches
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 9/12/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> XXX doesn't the above completely break the anti-wraparound guarantees?
>> And why couldn't we avoid the problem by pruning the previous tuple,
>> which is surely dead?

> We preserve anti-wraparound guarantees by not letting the relfrozenxid
> advance past the minimum of cut-off xid and xmin/xmax of not-yet-frozen
> tuples. Given that this is required to address corner case of DEAD tuple
> following a RD tuple, the final relfrozenxid would be very close to the
> cut-off xid. Isn't it ?
> We could have actually pruned the preceding RD tuples (as we do in
> vacuum full), but we were worried about missing some corner case
> where someone may still want to follow the chain from the RD tuple.

This seems all wrong to me.  We'd only be considering freezing a tuple
whose xmin precedes the global xmin.  If it has a predecessor, that
predecessor has xmax equal to this one's xmin, therefore also preceding
global xmin, therefore it would be seen as DEAD not RECENTLY_DEAD.
So we should never need to freeze a tuple that isn't the start of its
HOT chain.

Also, if you find a DEAD tuple after a RECENTLY_DEAD one, you can
certainly prune both, because what this tells you is that both tuples
are in fact dead to all observers.

            regards, tom lane

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: HOT documentation README
Next
From: "Florian G. Pflug"
Date:
Subject: Use latestCompletedXid to slightly optimize TransactionIdIsInProgress