Re: Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding
Date
Msg-id CAD21AoBVW5P8_xQhL_Gqds4DN3vsG_wa1eoZ_rtLJjJSPuBVAg@mail.gmail.com
Whole thread Raw
In response to Re:Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding  (ocean_li_996 <ocean_li_996@163.com>)
Responses Re: [BUG] Incorrect historic snapshot may be serialized to diskduring fast-forwarding
List pgsql-hackers
On Sat, Nov 22, 2025 at 10:33 PM ocean_li_996 <ocean_li_996@163.com> wrote:
>
> Hi ChangAo,
>
> At 2025-11-23 13:31:49, "cca5507" <cca5507@qq.com> wrote:
> >> The patch in attachment is better for me. What do you think?
> >
> >The v2-0001 LGTM.
> >
> >A small suggestion:
> >
> >We should move the 'break' out of the 'if', because we don't want it fall through to XLOG_HEAP2_REWRITE if we are
fast-forwarding.
>
> Fair. The patch updated is provided in attachment.
>

While I agree with your analysis, I'm not sure what actual problems it
could lead to in practice. Have you had a chance to reproduce this
behavior by using DDLs instead of a user-catalog table? IIUC the
problem can occur if a transaction makes catalog changes and writes
only NEW_CID WAL records without INVALIDATION WAL records. However,
I'm not sure there are such transactions in practice. IIUC it would
not be a problem in terms of logical decoding even if we don't include
their XIDs to the snapshot if they change only user-catalog tables. It
might be more future proof to mark transactions as catalog-changed
even when fast-forwarding a NEW_CID record, as you proposed, but I'd
like to confirm the actual problems first.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Bryan Green
Date:
Subject: Re: [PATCH] Allow complex data for GUC extra.
Next
From: Lukas Fittl
Date:
Subject: Re: pg_plan_advice