Re: sequencesync worker race with REFRESH SEQUENCES

On Fri, 24 Jul 2026 at 09:37, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Fri, 10 Jul 2026 at 10:22, Noah Misch <noah(at)leadboat(dot)com> 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