From 66289440ac65ea386cd138aeeed27b0032c2bb80 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Mon, 26 Jun 2023 09:48:26 +0300 Subject: [PATCH v2 1/2] Improve comment on why we need ctid->(cmin,cmax) mapping. Combocids are only part of the problem. Explain the problem in more detail. Discussion: https://www.postgresql.org/message-id/1ba2899e-77f8-7866-79e5-f3b7d1251a3e@iki.fi --- src/backend/replication/logical/snapbuild.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c index 0786bb0ab7..e403feeccd 100644 --- a/src/backend/replication/logical/snapbuild.c +++ b/src/backend/replication/logical/snapbuild.c @@ -41,10 +41,15 @@ * transactions we need Snapshots that see intermediate versions of the * catalog in a transaction. During normal operation this is achieved by using * CommandIds/cmin/cmax. The problem with that however is that for space - * efficiency reasons only one value of that is stored - * (cf. combocid.c). Since combo CIDs are only available in memory we log - * additional information which allows us to get the original (cmin, cmax) - * pair during visibility checks. Check the reorderbuffer.c's comment above + * efficiency reasons, the cmin and cmax are not included in WAL records. We + * cannot read the cmin/cmax from the tuple itself, either, because it is + * reset on crash recovery. Even if we could, we could not decode combocids + * which are only tracked in the original backend's memory. To work around + * that, heapam writes an extra WAL record (XLOG_HEAP2_NEW_CID) every time a + * catalog row is modified, which includes the cmin and cmax of the + * tuple. During decoding, we insert the ctid->(cmin,cmax) mappings into the + * reorder buffer, and use them at visibility checks instead of the cmin/cmax + * on the tuple itself. Check the reorderbuffer.c's comment above * ResolveCminCmaxDuringDecoding() for details. * * To facilitate all this we need our own visibility routine, as the normal -- 2.30.2