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 <[email protected]> wrote: > Hi Masahiko, ChangAo, > > Masahiko Sawada <[email protected]> 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 <[email protected]> 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 >
v4-0002-add-test.patch
Description: Binary data
