• Alvaro Herrera's avatar
    Rework tuple freezing protocol · 3b97e682
    Alvaro Herrera authored
    Tuple freezing was broken in connection to MultiXactIds; commit
    8e53ae025de9 tried to fix it, but didn't go far enough.  As noted by
    Noah Misch, freezing a tuple whose Xmax is a multi containing an aborted
    update might cause locks in the multi to go ignored by later
    transactions.  This is because the code depended on a multixact above
    their cutoff point not having any lock-only member older than the cutoff
    point for Xids, which is easily defeated in READ COMMITTED transactions.
    
    The fix for this involves creating a new MultiXactId when necessary.
    But this cannot be done during WAL replay, and moreover multixact
    examination requires using CLOG access routines which are not supposed
    to be used during WAL replay either; so tuple freezing cannot be done
    with the old freeze WAL record.  Therefore, separate the freezing
    computation from its execution, and change the WAL record to carry all
    necessary information.  At WAL replay time, it's easy to re-execute
    freezing because we don't need to re-compute the new infomask/Xmax
    values but just take them from the WAL record.
    
    While at it, restructure the coding to ensure all page changes occur in
    a single critical section without much room for failures.  The previous
    coding wasn't using a critical section, without any explanation as to
    why this was acceptable.
    
    In replication scenarios using the 9.3 branch, standby servers must be
    upgraded before their master, so that they are prepared to deal with the
    new WAL record once the master is upgraded; failure to do so will cause
    WAL replay to die with a PANIC message.  Later upgrade of the standby
    will allow the process to continue where it left off, so there's no
    disruption of the data in the standby in any case.  Standbys know how to
    deal with the old WAL record, so it's okay to keep the master running
    the old code for a while.
    
    In master, the old freeze WAL record is gone, for cleanliness' sake;
    there's no compatibility concern there.
    
    Backpatch to 9.3, where the original bug was introduced and where the
    previous fix was backpatched.
    
    Álvaro Herrera and Andres Freund
    3b97e682
heapam_xlog.h 11.5 KB