Update more obsolete multixact.c comments.
authorPeter Geoghegan <pg@bowt.ie>
Tue, 24 Jan 2023 23:15:33 +0000 (15:15 -0800)
committerPeter Geoghegan <pg@bowt.ie>
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 <shiy.fnst@fujitsu.com>
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