On Wed, Jul 8, 2026 at 4:12 PM Amit Kapila <[email protected]> wrote: > > On Wed, Jul 8, 2026 at 3:37 PM Hayato Kuroda (Fujitsu) > <[email protected]> wrote: > > > > > 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. > > > > Basically it sounds good, but it can slightly change the behavior if the > > old node > > has some subscriptions which have never been enabled. Till now, we just > > counted > > the number of subscriptions, thus we took into account them [1]. But after > > the > > patch they can be ignored; IIUC pg_upgrade can succeed in the case. > > > > If the change is OK, we can proceed with your (and Shlok-san's) idea. > > > > [1]: reproducer is below. > > 1. initialized old node with max_active_replication_origins=1 > > 2. created two subscriptions with (connect=false) > > 3. initialized new node with max_active_replication_origins=1 > > 4. ran pg_upgrade and it did error-out > > > > ``` > > $ pg_upgrade -b /usr/local/pgsql/bin/ -d old/ -D new/ -U postgres > > Performing Consistency Checks > > ----------------------------- > > ... > > Checking new cluster configuration for subscriptions > > "max_active_replication_origins" (1) must be greater than or equal to the > > number of subscriptions (2) in the old cluster > > Failure, exiting > > ``` > > > > Yes, I understand this case but I feel the old check is more > restrictive than required. We might want to even back-patch this small > part in future if we see any such user complaint. >
Okay, makes sense. thanks Shveta
