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: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>, "Wood, Dan" <hexpert@amazon.com>, pgsql-committers@postgresql.org, "Wong, Yi Wen" <yiwong@amazon.com>, Michael Paquier <michael.paquier@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2017-11-03T20:21:23Z
Lists: pgsql-hackers 
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>He means that the tuple that heap_update moves to page 1 (which will no
>longer be processed by vacuum) will contain a multixact that's older
>than relminmxid -- because it is copied unchanged by heap_update instead
>of properly checking against age limit.

I see. The problem is more or less with this heap_update() code:

    /*
     * And also prepare an Xmax value for the new copy of the tuple.  If there
     * was no xmax previously, or there was one but all lockers are now gone,
     * then use InvalidXid; otherwise, get the xmax from the old tuple.  (In
     * rare cases that might also be InvalidXid and yet not have the
     * HEAP_XMAX_INVALID bit set; that's fine.)
     */
    if ((oldtup.t_data->t_infomask & HEAP_XMAX_INVALID) ||
        HEAP_LOCKED_UPGRADED(oldtup.t_data->t_infomask) ||
        (checked_lockers && !locker_remains))
        xmax_new_tuple = InvalidTransactionId;
    else
        xmax_new_tuple = HeapTupleHeaderGetRawXmax(oldtup.t_data);

My naive guess is that we have to create a new MultiXactId here in at
least some cases, just like FreezeMultiXactId() sometimes does.

-- 
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.