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

macdice · macdice · commit 05e0aff58446 · 2020-03-12T18:09:14.000+13:00
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 2fc7af5, 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
@@ -3248,7 +3248,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);
 	}
 }

Original file line number	Diff line number	Diff line change
`@@ -3248,7 +3248,8 @@ RecordKnownAssignedTransactionIds(TransactionId xid)`
`3248`	`3248`	`next_expected_xid = latestObservedXid;`
`3249`	`3249`	`TransactionIdAdvance(next_expected_xid);`
`3250`	`3250`	`LWLockAcquire(XidGenLock, LW_EXCLUSIVE);`
`3251`		`- ShmemVariableCache->nextXid = next_expected_xid;`
	`3251`	`+ if (TransactionIdFollows(next_expected_xid, ShmemVariableCache->nextXid))`
	`3252`	`+ ShmemVariableCache->nextXid = next_expected_xid;`
`3252`	`3253`	`LWLockRelease(XidGenLock);`
`3253`	`3254`	`}`
`3254`	`3255`	`}`