Hi ChangAo,
Thanks for your analyze and report. At 2025-11-23 00:07:59, "cca5507" <[email protected]> wrote: >The main reason is that we don't handle XLOG_HEAP2_NEW_CID during >fast-forwarding, so we don't consider the insert as having a catalog change. Yeah. Refers to code below: ``` case XLOG_HEAP2_NEW_CID: if (!ctx->fast_forward) { xl_heap_new_cid *xlrec; xlrec = (xl_heap_new_cid *) XLogRecGetData(buf->record); SnapBuildProcessNewCid(builder, xid, buf->origptr, xlrec); break; } ``` It is clear that transaction is skipped set has catalog change (in SnapBuildProcessNewCid) duraing fast forward. However, in practice this does not cause any actual issues, because for the "real" system catalogs (those not specified via user_catalog_table and thus critical for decoding), any HEAP2_NEW_CID changes are always accompanied by some invalid messages. As a result, they are ultimately marked as catalog changes. Still, from a code perspective, I would prefer fixing this behavior for logical consistency across the snapshot builder, even if it doesn’t manifest as a runtime problem today. But we can not provide a test case. >Attach a patch to fix it. The patch in attachment is better for me. What do you think? Bset regards, Haiyang Li
v2-0001-Handle-XLOG_HEAP2_NEW_CID-in-fast-forward.patch
Description: Binary data
