On Wed, Jul 29, 2026 at 12:25 PM vignesh C <[email protected]> wrote: > > 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. >
Agreed, I also feel it would be difficult to detect all ERRORs and skip to next sequence sync. So, we can leave this at least for now. > 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. > Right, so we can leave this one as well. > 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. > Make sense. We can leave this one as well. > 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. > The bullet point: "Incremental sequence changes are not replicated...." on the Restriction page explained the limitations related to sequences, so I don't see any need to update this section of docs. -- With Regards, Amit Kapila.
