Re: Improve comment on cid mapping (was Re: Adding CommandID to heap xlog records) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Improve comment on cid mapping (was Re: Adding CommandID to heap xlog records)
Date
Msg-id 20230626211534.2fluo3u2x5fle2jr@awork3.anarazel.de
Whole thread Raw
In response to Improve comment on cid mapping (was Re: Adding CommandID to heap xlog records)  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
Hi,

On 2023-06-26 09:57:56 +0300, Heikki Linnakangas wrote:
> 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

LGTM


> From 9140a0d98fd21b595eac6d111175521a6b1a9f1b Mon Sep 17 00:00:00 2001
> From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
> Date: Mon, 26 Jun 2023 09:56:02 +0300
> Subject: [PATCH v2 2/2] Remove redundant check for fast_forward.
> 
> We already checked for it earlier in the function.
> 
> Discussion: https://www.postgresql.org/message-id/1ba2899e-77f8-7866-79e5-f3b7d1251a3e@iki.fi
> ---
>  src/backend/replication/logical/decode.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/backend/replication/logical/decode.c b/src/backend/replication/logical/decode.c
> index d91055a440..7039d425e2 100644
> --- a/src/backend/replication/logical/decode.c
> +++ b/src/backend/replication/logical/decode.c
> @@ -422,8 +422,7 @@ heap2_decode(LogicalDecodingContext *ctx, XLogRecordBuffer *buf)
>      switch (info)
>      {
>          case XLOG_HEAP2_MULTI_INSERT:
> -            if (!ctx->fast_forward &&
> -                SnapBuildProcessChange(builder, xid, buf->origptr))
> +            if (SnapBuildProcessChange(builder, xid, buf->origptr))
>                  DecodeMultiInsert(ctx, buf);
>              break;
>          case XLOG_HEAP2_NEW_CID:
> -- 
> 2.30.2

LGTM^2

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Optimize walsender handling invalid messages of 'drop publication'
Next
From: Kirk Wolak
Date:
Subject: Re: Do we want a hashset type?