On Friday, March 6, 2026 4:52 PM Chao Li <[email protected]> wrote: > > I just started reviewing this patch and wanted to first discuss the design. >
Thanks for reviewing. > The current approach introduces a long-lived sync worker for any subscription > that has at least one sequence. I noticed a previous email suggesting that > this approach is “acceptable”, but it still seems like a big runtime cost. Currently in the patch, the sequence sync worker operates at a dynamic interval (between 2 and 30 seconds), adjusting based on how frequently the sequence is updated, and only synchronizes when the sequence has actually diverged from the publisher. So while it's a long-lived worker, I think its runtime impact is acceptable. > What I had in mind instead is whether we could extend the WAL decoding > protocol to send RM_SEQ_ID over the logical replication stream, so that > sequence synchronization becomes part of logical replication itself. That approach was explored in depth during earlier discussions, but it was ultimately set aside due to the complexity and correctness challenges it would introduce into logical decoding. Adding sequence information to the replication stream would require significant changes to the decoding machinery, and given that the primary use case is to support upgrades, the trade-off didn't seem justified. You can find a detailed breakdown of the design considerations and the reasoning behind the decision in [1]. > That would make it essentially event-driven and close to zero cost at runtime, > rather than relying on periodic polling. I don't think so. Even with an event-driven model, there's still a cost, decoding sequence changes would add overhead to walsenders on the publisher that needs to replicate sequences. So it's just a different distribution of the overhead. > There is also one case I haven’t seen discussed yet. Suppose the standby side > inserts a tuple into a table that is under logical replication. This might not > immediately cause a tuple-level replication conflict, but it could advance the > sequence locally. In that case, the standby sequence could diverge from the > primary sequence and remain out of sync indefinitely. How should that > situation be handled? This scenario was also considered in earlier discussions, see [2]. The divergence issue you mentioned is not introduced by the sequence sync worker; It is considered as a logical conflict and resolving it would require user intervention or a future enhancement to handle such conflicts automatically. [1] https://www.postgresql.org/message-id/CAA4eK1LC%2BKJiAkSrpE_NwvNdidw9F2os7GERUeSxSKv71gXysQ%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAA4eK1LLkxqeZ_GDjquzxY3bwN3yV8Nq7brvgyOBiWOXtWt4Jg%40mail.gmail.com Best Regards, Hou zj
