Re: sequencesync worker race with REFRESH SEQUENCES

On Wed, Jul 29, 2026 at 12:25 PM vignesh C <vignesh21(at)gmail(dot)com> 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.