Re: sequencesync worker race with REFRESH SEQUENCES

On Tue, Jul 14, 2026 at 8:21 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jul 13, 2026 at 5:46 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > 2)
> > The fix will solve the purpose. But I have a doubt for the check in
> > copy_sequences(). Say a few sequences are already in the INIT state,
> > and the subscription is then repointed to a pre-PG19 publisher. Would
> > the apply worker keep launching the sequence sync worker, only for it
> > to exit each time with this error of copy_sequences? Is my
> > understanding correct? If so, is there a way to avoid launching the
> > sequence sync worker altogether when connected to a pre-PG19
> > publisher? We do have 'LogRepWorkerWalRcvConn' in the apply worker to
> > check the version.
> >
>
> Good question. I think to handle the case you pointed and even REFRESH
> SEQUENCES case, isn't it better to raise an ERROR when the user is
> trying to point connection to a version prior to 19 and the subscriber
> has sequences? For example, we do something similar retain_dead_tuples
> parameter in AlterSubscription, see handling of
> ALTER_SUBSCRIPTION_SERVER/ALTER_SUBSCRIPTION_CONNECTION->check_pub_rdt
> in AlterSubscription().
>

Yes, that makes sense, as the user will not be able to change the
connection string unless they modify the subscription to remove
sequences.

thanks
Shveta