From 18d6217b3c5a70b12812d8abdbf5af2a18e0a184 Mon Sep 17 00:00:00 2001
From: Zhang Mingli <avamingli@gmail.com>
Date: Sat, 22 Oct 2022 11:11:39 +0800
Subject: [PATCH v48] remove some outdate codes comments about
 xidWrapLimit/xidStopLimit/xidWarnLimit

---
 src/backend/access/transam/varsup.c  | 16 ----------------
 src/backend/storage/ipc/procarray.c  |  4 ++--
 src/backend/storage/lmgr/predicate.c | 25 -------------------------
 src/include/access/transam.h         |  4 ----
 4 files changed, 2 insertions(+), 47 deletions(-)

diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 53c79d9a31..1a285a3cb6 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -80,19 +80,6 @@ GetNewTransactionId(bool isSubXact)
 	full_xid = ShmemVariableCache->nextXid;
 	xid = XidFromFullTransactionId(full_xid);
 
-	/*----------
-	 * Check to see if it's safe to assign another XID.  This protects against
-	 * catastrophic data loss due to XID wraparound.  The basic rules are:
-	 *
-	 * If we're past xidVacLimit, start trying to force autovacuum cycles.
-	 * If we're past xidWarnLimit, start issuing warnings.
-	 * If we're past xidStopLimit, refuse to execute transactions, unless
-	 * we are running in single-user mode (which gives an escape hatch
-	 * to the DBA who somehow got past the earlier defenses).
-	 *
-	 * Note that this coding also appears in GetNewMultiXactId.
-	 *----------
-	 */
 	if (TransactionIdFollowsOrEquals(xid, ShmemVariableCache->xidVacLimit))
 	{
 		/*
@@ -295,9 +282,6 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
 	 * We'll start trying to force autovacuums when oldest_datfrozenxid gets
 	 * to be more than autovacuum_freeze_max_age transactions old.
 	 *
-	 * Note: guc.c ensures that autovacuum_freeze_max_age is in a sane range,
-	 * so that xidVacLimit will be well before xidWarnLimit.
-	 *
 	 * Note: autovacuum_freeze_max_age is a PGC_POSTMASTER parameter so that
 	 * we don't have to worry about dealing with on-the-fly changes in its
 	 * value.  It doesn't look practical to update shared state from a GUC
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c
index 47589ec53b..d1e88f3883 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -1870,8 +1870,8 @@ ComputeXidHorizons(ComputeXidHorizonsResult *h)
 		 * predictable transaction rate, but it offers some protection when
 		 * there's no walsender connection.  Note that we are assuming
 		 * vacuum_defer_cleanup_age isn't large enough to cause wraparound ---
-		 * so guc.c should limit it to no more than the xidStopLimit threshold
-		 * in varsup.c.  Also note that we intentionally don't apply
+		 * so guc_tables.c limits it with a proper threshold.
+		 * Also note that we intentionally don't apply
 		 * vacuum_defer_cleanup_age on standby servers.
 		 */
 		h->oldest_considered_running =
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index 529e01eb8f..6e9c017e58 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -1090,31 +1090,6 @@ CheckPointPredicate(void)
 		/*----------
 		 * The SLRU is no longer needed. Truncate to head before we set head
 		 * invalid.
-		 *
-		 * XXX: It's possible that the SLRU is not needed again until XID
-		 * wrap-around has happened, so that the segment containing headPage
-		 * that we leave behind will appear to be new again. In that case it
-		 * won't be removed until XID horizon advances enough to make it
-		 * current again.
-		 *
-		 * XXX: This should happen in vac_truncate_clog(), not in checkpoints.
-		 * Consider this scenario, starting from a system with no in-progress
-		 * transactions and VACUUM FREEZE having maximized oldestXact:
-		 * - Start a SERIALIZABLE transaction.
-		 * - Start, finish, and summarize a SERIALIZABLE transaction, creating
-		 *   one SLRU page.
-		 * - Consume XIDs to reach xidStopLimit.
-		 * - Finish all transactions.  Due to the long-running SERIALIZABLE
-		 *   transaction, earlier checkpoints did not touch headPage.  The
-		 *   next checkpoint will change it, but that checkpoint happens after
-		 *   the end of the scenario.
-		 * - VACUUM to advance XID limits.
-		 * - Consume ~2M XIDs, crossing the former xidWrapLimit.
-		 * - Start, finish, and summarize a SERIALIZABLE transaction.
-		 *   SerialAdd() declines to create the targetPage, because headPage
-		 *   is not regarded as in the past relative to that targetPage.  The
-		 *   transaction instigating the summarize fails in
-		 *   SimpleLruReadPage().
 		 */
 		tailPage = serialControl->headPage;
 		serialControl->headPage = -1;
diff --git a/src/include/access/transam.h b/src/include/access/transam.h
index e7cf1206df..d0aec45981 100644
--- a/src/include/access/transam.h
+++ b/src/include/access/transam.h
@@ -227,10 +227,6 @@ FullTransactionIdAdvance(FullTransactionId *dest)
  * OID and XID assignment state.  For largely historical reasons, there is
  * just one struct with different fields that are protected by different
  * LWLocks.
- *
- * Note: xidWrapLimit and oldestXidDB are not "active" values, but are
- * used just to generate useful messages when xidWarnLimit or xidStopLimit
- * are exceeded.
  */
 typedef struct VariableCacheData
 {
-- 
2.34.1