Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Tue, Oct 3, 2017 at 8:43 PM, Wong, Yi Wen <yiwong@amazon.com> wrote:
> My interpretation of README.HOT is the check is just to ensure the chain is continuous; in which case the condition
shouldbe:
 
>
>>                 if (TransactionIdIsValid(priorXmax) &&
>>                         !TransactionIdEquals(priorXmax, HeapTupleHeaderGetRawXmin(htup)))
>>                         break;
>
> So the difference is GetRawXmin vs GetXmin, because otherwise we get the FreezeId instead of the Xmin when the
transactionhappened
 

I was thinking along similar lines.

> The interesting consequence of changing that is the prune seems to get the entire chain altogether with Dan's
repro...I've run it a couple of times and have consistently gotten the following page
 
>
>  lp | t_ctid | lp_off | lp_flags | t_infomask | t_infomask2
> ----+--------+--------+----------+------------+-------------
>   1 | (0,1)  |   8152 |        1 |       2818 |           3
>   2 |        |      7 |        2 |            |
>   3 |        |      0 |        0 |            |
>   4 |        |      0 |        0 |            |
>   5 |        |      0 |        0 |            |
>   6 |        |      0 |        0 |            |
>   7 | (0,7)  |   8112 |        1 |      11010 |       32771
> (7 rows)

That's also what I see. This is a good thing, I think; that's how we
ought to prune.

-- 
Peter Geoghegan


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers