Hi, On Mon, Aug 10, 2026 at 12:25 AM torikoshia <[email protected]> wrote: > > On 2026-07-21 18:57, solai v wrote: > > Thank you for the patch. I reviewed and tested this patch on my > > PostgreSQL 19beta2 tree. The patch did not apply cleanly on my branch > > because of a context mismatch in > > src/test/subscription/t/020_messages.pl. > > Sorry for the late reply, and thanks for testing the patch. > > Just to clarify, I tried applying v2 directly to the REL_19_BETA2 tag > (7873db5369b), > and git apply succeeded without any conflicts, including the change to > src/test/subscription/t/020_messages.pl. > > I also checked whether that file differs between REL_19_BETA2 and > master, but found no differences: > > $ git diff REL_19_BETA2 master -- > src/test/subscription/t/020_messages.pl > $ > > The same is true for REL_19_STABLE and master: > $ git diff REL_19_STABLE master -- > src/test/subscription/t/020_messages.pl > $ > > So I am not sure what caused the context mismatch. > > > Separately, I proposed fixing the issue in minor releases, but the v2 > patch does not apply cleanly to 14 and 15. > Attached a patch for these versions. >
I'm still studying this patch but I want to clarify: was the problem you faced caused by logical decoding showing different types of changes(insert/update/delete/truncate/message) with the same LSN? IIUC logical decoding of MULTI_INSERT emits all INSERT changes with the same LSN, so I think showing the same LSN multiple times is fine. One possible reason why the message uses endptr instead of origptr is for non-transactional messages; on receiver sides a non-transactional message would be handled as a separate transaction, so it would be useful to use endptr as the confirmed flush position. That said, it doesn't apply for transactional messages. While I agree that logical decoding uses origptr of logical decoding messages as their LSN, I think having its endptr is also useful for the above reason. For instance, I proposed to extend logical decoding message handling[1] so that extension can define a function to handle logical decoding messages on the subscriber. If we use origptr as the flushed position, the same message is replicated again after the server restart even if the subscriber has committed the message as a separate transaction and sent an ack to the publisher. So an alternative idea would be to use origptr for transactional messages and endptr for non-transactional ones. With this idea, a transactional message's LSN could coincide with the LSN reported for the preceding COMMIT, or for a preceding non-transactional message. I think that is acceptable for the same reason as MULTI_INSERT above: what matters is that the LSN identifies the record the change came from, not that it is unique. I'm hesitant to backpatch it. What this issue tells us is that consumers do look at the LSN of individual changes and possibly persist it, and use it to decide where to resume and what has already been processed. If we change the LSN we report in a minor release, a position that a consumer recorded under the old behavior will be interpreted under the new one after the upgrade. Whether that ends up re-processing changes, skipping them, or failing to locate the resume point depends on the consumer, and none of those seems like something an operator should have to expect from a minor upgrade. There is no correctness problem within PostgreSQL here. So I think this is pushed to master only, with the current behavior documented in the back branches. Consumers hitting this can handle it on their side in the meantime. Regards, [1] https://postgr.es/m/CAD21AoCTNGiddikkUcDKj5QLnsg-51bpr-o6L-GTHWZL4ZFYtQ%40mail.gmail.com -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
