Re: Another possible corruption bug in 9.3.2 or possibly a known MultiXact problem?

Andres Freund wrote:

> static void
> heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
> {
> ...
>     HeapTupleHeaderClearHotUpdated(htup);
>     HeapTupleHeaderSetXmax(htup, xlrec->locking_xid);
>     HeapTupleHeaderSetCmax(htup, FirstCommandId, false);
>     /* Make sure there is no forward chain link in t_ctid */
>     htup->t_ctid = xlrec->target.tid;
> ...
> }

I think the fix is to reset HOT_UPDATED and t_ctid only if the infomask
says the tuple is LOCKED_ONLY, per the attached patch.  This matches
what heap_lock_tuple is doing originally:

    if (HEAP_XMAX_IS_LOCKED_ONLY(new_infomask))
        HeapTupleHeaderClearHotUpdated(tuple->t_data);
    HeapTupleHeaderSetXmax(tuple->t_data, xid);

    /*
     * Make sure there is no forward chain link in t_ctid.    Note that in the
     * cases where the tuple has been updated, we must not overwrite t_ctid,
     * because it was set by the updater.  Moreover, if the tuple has been
     * updated, we need to follow the update chain to lock the new versions of
     * the tuple as well.
     */
    if (HEAP_XMAX_IS_LOCKED_ONLY(new_infomask))
        tuple->t_data->t_ctid = *tid;

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services