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

Hi ChangAo, Haiyang, and Masahiko,
I reviewed v4 at the CommitFest branch d4014e6ed86. On the unpatched
parent, I reproduced both the incorrect serialized snapshot
and the resulting failure in an output plugin's catalog lookup. I verified
that v4 fixes both cases.

Following Masahiko's question about a DDL-only reproducer, I inspected the
WAL generated in my test environment by:
* CREATE TABLE
* ALTER TABLE ADD COLUMN
* CREATE INDEX
* COMMENT ON TABLE
* GRANT on a table
* DROP TABLE

Each tested case generated both XLOG_HEAP2_NEW_CID and
XLOG_XACT_INVALIDATIONS. The latter already causes
ReorderBufferXidSetCatalogChanges() to be called, including during
fast-forwarding. Therefore, these transactions were tracked as
catalog-changing even without v4, and I could not reproduce the bug with
these representative DDL statements.

I also attached a test-only patch that fast-forwards over a NEW_CID without
XLOG_XACT_INVALIDATIONS and verifies that the transaction's XID is retained
in the serialized snapshot. The test fails without v4 and passes with it.
The patch applies on top of v4-0001 and can be folded into a future
revision if the approach is acceptable.

Regards,
Yuya Shinde

On Mon, Jan 26, 2026 at 11:19 PM ocean_li_996 <ocean_li_996(at)163(dot)com> wrote:

> Hi Masahiko, ChangAo,
>
> Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> 2025-12-30 01:10:01 wrote:
> > 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.
>
> Yeah, I haven’t identified any actual issue in practice. My observations
> are
> purely based on code-level logic analysis.
>
> cca5507 <cca5507(at)qq(dot)com> Sat, 17 Jan 2026 23:56:17 +0800 wrote:
> > The commit message of 'user_catalog_table' says:
> >
> > ```
> > Replication solutions built around the logical decoding machinery
> > will likely need to set this operation for their configuration
> > tables; it might also be needed by extensions which perform table
> > access in their output functions.
> > ```
> >
> > So if there is an extension using the incorrect snapshot to scan user
> > catalog tables, it will get the wrong result, right?
>
> I agree with your analysis. The introduction of user_catalog_table is
> intended to
> ensure that the historical MVCC in logical replication can observe the
> historical
> state of this table. Consequently, transactions on this table should be
> tracked by
> the historical snapshot — even while in the fast forward state.
>
> Regards
> Haiyang Li
>