On Fri, Oct 30, 2026 at 8:16 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Hi,
> Proposed fix > ======= > Origins for tablesync workers can exist only while the synchronization is > on-going, > so my idea is does not allow upgrading during the synchronization. For now, > the check function check_old_cluster_subscription_state() ensures all sync > are done, > but it's called when the source is PG17+, which supports migrating the > pg_subscription_rel. > I think we can do for the same all cases. > > Note > ==== > check_old_cluster_subscription_state() also ensures that all subscriptions > have > the respective replication origins. For now upgrading PG16- node can be done > even if subscriptions do not have origins, but such a case would be > additionally > rejected after the fix. > I felt it's harmless because there are no benefits for origin-missing > subscriptions, > but please post here if you have any doubts. > > How do you feel? > Hi Kuroda-san, +1. I’ve done this in the attached v22: check_old_cluster_subscription_state() now runs for all supported old cluster versions, not only 17 and later. I tested an upgrade from a PG10 subscriber to HEAD. pg_upgrade now rejects both a relation in ‘d’ state and a subscription with a missing origin. A clean upgrade preserves all origin IDs and remote_lsn values. I also agree that rejecting origin-less subscriptions is harmless, so the fallback in CreateSubscription() that created a missing origin is removed, since it can no longer be reached. Regards, Ajin Cherian Fujitsu Australia
v22-0001-Preserve-subscription-OIDs-during-pg_upgrade.patch
Description: Binary data
v22-0002-Preserve-replication-origin-IDs-during-pg_upgrad.patch
Description: Binary data
