Re: pg_upgrade and logical replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-10-27T11:35:39Z
Lists: pgsql-hackers
On Fri, Oct 27, 2023 at 12:09 PM vignesh C <vignesh21@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.
Commits
-
pg_upgrade: Retrieve subscription count more efficiently.
- 73de50e13e39 17.0 landed
- 364509a2e7f9 18.0 landed
-
Fix random failure in 004_subscription.
- 677a45c4ae16 17.0 landed
-
Fix 004_subscription.pl to allow its usage in --link mode.
- f17529b71097 17.0 landed
-
Allow upgrades to preserve the full subscription's state.
- 9a17be1e244a 17.0 landed
-
Prevent startup of logical replication launcher during pg_upgrade
- 7021d3b17664 17.0 landed