On Tue, Jul 14, 2026 at 8:21 AM Amit Kapila <[email protected]> wrote: > > On Mon, Jul 13, 2026 at 5:46 PM shveta malik <[email protected]> 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
