On Wed, Jul 8, 2026 at 11:51 AM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > > For this reason, my inclination is to revert to the previous > > implementation, where we compare old_cluster.nsubs with > > max_active_replication_origins. But I'd like to hear what others think > > before we make this change. > > But if origin created by users (or any extensions) have already been tracking > the > Remote_lsn, they should be taken into account. If there are three enabled > subscriptions, two active user-created origins but the max_active_origin is > set > to three on the new node, the upgrading should fail. >
Fair point but isn't it sufficient to check the tracked_origins rather than all origins? In docs of max_active_replication_origins, we say: "Setting it to a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status) will prevent the server from starting." which suggests here we should have a tight check of tracked_origins against max_active_replication_origins. > I prefer to preserve the current behavior of the patch, which compares > max_active_origin and total number of origins. It might cause the > false-positive, > but even now it can happen. E.g., if there was a subscription which has never > been enabled. > I think it is possible that non-tracked origins (e.g for subscriptions that get enabled only after upgrade) could lead to ERROR after upgrade and starting the server but users can always increase max_active_replication_origins to accommodate that which she anyway needs to do even before upgrade. -- With Regards, Amit Kapila.
