RE: [PATCH] Support automatic sequence replication

On Friday, March 6, 2026 4:52 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> 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