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

Hi ChangAo, At 2025-11-23 13:31:49, "cca5507" 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.

Re:Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT

Hi, Sorry for the direct CC. Given your expertise in logical replication and your dedication to improving its functionality, I think the issue mentioned in [1] may be worth some attention. If you have time, I am appreciate your thoughts or opinions on the issue. Thanks and sorry again fo

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

Hi ChangAo, Thanks for your analyze and report. At 2025-11-23 00:07:59, "cca5507" 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:

Re: Fix logical decoding not track transaction duringSNAPBUILD_BUILDING_SNAPSHOT

Hi ChaoAo, At 2025-11-22 18:34:23, "cca5507" wrote: >One important thing is that we must not skip any call to >ReorderBufferXidSetCatalogChanges() (direct or indirect) during >fast-forwarding or building snapshot, because the historic snapshot only >tracks txns with catalog changes, the v6-0004

Re:Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT

Hi Ajin & Bertrand, I missed CC you in last email. Just for your infomation. No defence. Best regards, Haiyang Li

Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT

Hi all, I would like to share a logical replication bug and some possible fixes. It seems that this bug has existed since logical replication was first introduced, so it has been around for quite some time. In fact, the previously reported issues [1], [2], [3] were all caused by this bug. # P

Re: minor improvement in snapbuild: use existing interface and removefake code

Hi ChangAo, Thanks for your comments. At 2025-11-18 10:47:20, "cca5507" wrote: > Is there a test case can reproduce the assert fail in > SnapBuildGetOrBuildSnapshot()? > After exploring the logicalmsg_decode()，I think the Assert in SnapBuildGetOrBuildSnapshot() will not fail. But the asse

Re: minor improvement in snapbuild: use existing interface and remove fake code

Hi yuefei, Thanks for your review. At 2025-11-18 09:13:12, "Yuefei Shi" wrote: > - /* only build a new snapshot if we don't have a prebuilt one */ > - if (builder->snapshot == NULL) > - { > - builder->snapshot = SnapBuildBuildSnapshot(builder); > - /* increase refcount for the snapshot builder

minor improvement in snapbuild: use existing interface and remove fake code

Hi hackers, While reviewing the snapbuild implementation, I noticed several small changes that could improve code clarity, correctness, and reuse. I have prepared a patch with these modifications (attached): 1. Removed the Assert in SnapBuildGetOrBuildSnapshot(). When called from logicalmsg_de

Re: [PATCH] Add a guc parameter to control limit clause adjust path cost.

There were some formatting display issues with my previous email reply, so I’m using another email account to send this message. "Tom Lane" Sun, 02 Nov 2025 12:44:13 -0500 write: > I think this is a pretty bad solution as given. A global GUC switch > is an extremely blunt instrument and hard