On Fri, 24 Jul 2026 at 09:37, vignesh C <[email protected]> wrote: > > On Fri, 10 Jul 2026 at 10:22, Noah Misch <[email protected]> wrote: > > > The other findings are gray areas, perhaps. > > There are a few remaining issues that I will discuss in a subsequent email.
I had a look at the remaining 4 findings that were left, here are my thoughts: Finding 3: `run_as_owner=false`: one un-SET-ROLE-able sequence owner stalls all sequence sync, unattributed. I think this need not be handled. We have already handled the most common per-sequence failure cases, such as sequence mismatch, insufficient privileges on the publisher, insufficient privileges on the subscriber, and sequences skipped because they were removed. Those are common scenarios that users are expected to encounter during sequence synchronization. The case described here requires the subscription owner to be unable to SET ROLE to the sequence owner when run_as_owner = false, which is a much less common configuration issue. We can revisit and do it if this gets reported from the field. Finding 5: Sequencesync worker starved by tablesync workers; REFRESH SEQUENCES silently deferred This is handled like this intentionally and need not be handled. The sequence synchronization worker intentionally shares the same max_sync_workers_per_subscription budget as table synchronization workers. This is an existing design choice to limit the number of concurrent synchronization workers for a subscription, and the documentation already states that both table and sequence synchronization workers consume this budget. Prioritizing table synchronization is also intentional, since a subscription is generally not considered fully initialized until table synchronization has completed. Delaying sequence synchronization until worker slots become available is therefore expected behavior rather than starvation. Finding 10: REFRESH SEQUENCES vs concurrent subscriber DROP SEQUENCE: internal XX000 errors I don't think this needs to be addressed. REFRESH SEQUENCES is an administrative command that is expected to be run infrequently, and concurrently dropping replicated sequences on the subscriber while it is executing is not a common or recommended operation. The reported failures arise only from this narrow race and are transient. After such a failure, the sequence synchronization worker will be restarted automatically. On the subsequent run, it will either synchronize the remaining sequences successfully or report an appropriate error. Finding 18: Restrictions bullet still claims only tables can be replicated I don't think this needs to be changed. The restriction is describing the kinds of relations that participate in logical replication itself, i.e., replicating changes from the publisher to the subscriber. Sequences are different—they do not participate in ongoing logical replication. The current feature only provides synchronization of sequence values on demand (during CREATE SUBSCRIPTION with copy_data, ALTER SUBSCRIPTION ... REFRESH PUBLICATION, or ALTER SUBSCRIPTION ... REFRESH SEQUENCES); subsequent sequence changes are not replicated automatically. Therefore, I don't think the existing restriction is misleading. The "Replicating Sequences" section already explains the supported behavior and its limitations, making the distinction between table replication and sequence synchronization clear. Changing this bullet could instead blur that distinction by implying that sequences participate in logical replication in the same way as tables, which they currently do not. Regards, Vignesh
