On Fri, Oct 27, 2023 at 12:09 PM vignesh C <vignes...@gmail.com> wrote: > > Apart from this I'm still checking that the old cluster's subscription > relations states are READY state still, but there is a possibility > that SYNCDONE or FINISHEDCOPY could work, this needs more thought > before concluding which is the correct state to check. Let' handle > this in the upcoming version. >
I was analyzing this part and it seems it could be tricky to upgrade in FINISHEDCOPY state. Because the system would expect that subscriber would know the old slotname from oldcluster which it can drop at SYNCDONE state. Now, as sync_slot_name is generated based on subid, relid which could be different in the new cluster, the generated slotname would be different after the upgrade. OTOH, if the relstate is INIT, then I think the sync could be performed even after the upgrade. Shouldn't we at least ensure that replication origins do exist in the old cluster corresponding to each of the subscriptions? Otherwise, later the query to get remote_lsn for origin in getSubscriptions() would fail. -- With Regards, Amit Kapila.
