On Wed, Apr 29, 2026 at 2:11 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Dear Ajin, > > > Sequence of Events During Upgrade > > > > 1. pg_dumpall dumps all non-subscription replication origins from the > > old cluster with their roidents and LSN positions. > > 2. pg_dump dumps each subscription, but now records the old roident > > alongside the subscription info. > > 3. During restore, pg_dumpall's output recreates non-subscription > > origins on the new cluster with their original roidents via > > binary_upgrade_create_replication_origin(). > > To confirm, why do we have to handle separately for subscription-associated > origins? I'm thinking it's not needed if the subscription's OID is preserved > during the upgrade. >
I’m not sure how preserving the subscription OID would ensure that the origin ID is also preserved for sub-associated origins. Could you please elaborate? As I understand it, roident values are assigned independently during origin creation. Even if subscription OIDs are preserved, the origin IDs could still be reassigned differently on the new cluster. For example, suppose we have two subscriptions, sub1 and sub2, with roident values 2 and 3, assuming 1 was previously used and dropped. After upgrade, origin creation may start allocating from 1 again, resulting in roident values 1 and 2 instead. Since pg_commit_ts stores the numeric roident, not the origin name, this mismatch could still lead to incorrect conflict detection. Wouldn’t that result in the same wrong conflict detection issue we are trying to avoid? Please let me know if my understanding is wrong. thanks Shveta
