Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: "Wong, Yi Wen" <yiwong@amazon.com>
Cc: "Wood, Dan" <hexpert@amazon.com>, Michael Paquier <michael.paquier@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2017-10-04T15:40:32Z
Lists: pgsql-hackers 
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 should be:
>
>>                 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 transaction happened

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

Commits

  1. Backport addition of rs_old_rel to rewriteheap's state.

  2. Perform a lot more sanity checks when freezing tuples.

  3. Revert bogus fixes of HOT-freezing bug

  4. Fix traversal of half-frozen update chains

  5. Fix freezing of a dead HOT-updated tuple

  6. During index build, check and elog (not just Assert) for broken HOT chain.

  7. Fix WAL replay of locking an updated tuple

  8. Change the way we mark tuples as frozen.