Fix nextXid tracking bug on standbys (9.5-11 only).

RecordKnownAssignedTransactionIds() should never move
nextXid backwards.  Before this commit, that could happen
if some other code path had advanced it without advancing
latestObservedXid.

One consequence is that a well timed XLOG_CHECKPOINT_ONLINE
could cause hot standby feedback messages to get confused
and report an xmin from a future epoch, potentially allowing
vacuum to run too soon on the primary.

Repair, by making sure RecordKnownAssignedTransactionIds()
can only move nextXid forwards.

In release 12 and master, this was already done by commit
2fc7af5e, which consolidated similar code and straightened
out this bug.  Back-patch to supported releases before that.

Author: Eka Palamadai <ekanatha@amazon.com>
Discussion: https://postgr.es/m/98BB4805-D0A2-48E1-96F4-15014313EADC@amazon.com

diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index f1bbc4567c25017f0c28d9d18dc00965ff383ca6..0389af5b98b22dbc3cdba421d3c8ae1b1e29417d 100644 (file)
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -3016,7 +3016,8 @@ RecordKnownAssignedTransactionIds(TransactionId xid)
                next_expected_xid = latestObservedXid;
                TransactionIdAdvance(next_expected_xid);
                LWLockAcquire(XidGenLock, LW_EXCLUSIVE);
-               ShmemVariableCache->nextXid = next_expected_xid;
+               if (TransactionIdFollows(next_expected_xid, ShmemVariableCache->nextXid))
+                       ShmemVariableCache->nextXid = next_expected_xid;
                LWLockRelease(XidGenLock);
        }
 }