Update more obsolete multixact.c comments.
authorPeter Geoghegan <[email protected]>
Tue, 24 Jan 2023 23:15:33 +0000 (15:15 -0800)
committerPeter Geoghegan <[email protected]>
Tue, 24 Jan 2023 23:15:33 +0000 (15:15 -0800)
Update some remaining comments in multixact.c that still described SLRU
truncation as happening in the checkpointer, rather than during VACUUM.

Follow-up to commit 5212d447.

Shi yu, with tweaks by me.

Author: Shi yu <[email protected]>
Discussion: https://postgr.es/m/OSZPR01MB631066BF246F8F74E83222FCFDC69@OSZPR01MB6310.jpnprd01.prod.outlook.com

src/backend/access/transam/multixact.c

index e75e1fdf74031ffe6b51b208741b9bb8eae5e965..fe6698d5ffa4b7b55e9fe756fcfd264f2ea532a7 100644 (file)
@@ -261,7 +261,7 @@ typedef struct MultiXactStateData
     * we compute it (using nextMXact if none are valid).  Each backend is
     * required not to attempt to access any SLRU data for MultiXactIds older
     * than its own OldestVisibleMXactId[] setting; this is necessary because
-    * the checkpointer could truncate away such data at any instant.
+    * the relevant SLRU data can be concurrently truncated away.
     *
     * The oldest valid value among all of the OldestMemberMXactId[] and
     * OldestVisibleMXactId[] entries is considered by vacuum as the earliest
@@ -669,8 +669,8 @@ MultiXactIdSetOldestMember(void)
  *
  * We set the OldestVisibleMXactId for a given transaction the first time
  * it's going to inspect any MultiXactId.  Once we have set this, we are
- * guaranteed that the checkpointer won't truncate off SLRU data for
- * MultiXactIds at or after our OldestVisibleMXactId.
+ * guaranteed that SLRU data for MultiXactIds >= our own OldestVisibleMXactId
+ * won't be truncated away.
  *
  * The value to set is the oldest of nextMXact and all the valid per-backend
  * OldestMemberMXactId[] entries.  Because of the locking we do, we can be