On Tue, 8 Sept 2026 at 17:51, Marco Nenciarini <[email protected]> wrote: > > v2 attached. Same design as v1, rebased on current master.
> On Tue, Aug 11, 2026 02:56 PM, Marco Nenciarini > <[email protected]> wrote: >> >> Short version: after pg_upgrade on a primary, resyncing its standbys today >> means a full re-clone, because there's no shared WAL history across the >> upgrade boundary for pg_rewind or incremental pg_basebackup to use. For a >> multi-terabyte database that's a real problem. Attached are three patches: We can just rsync replicas from primary after primary upgrade, can't we? fetching only catalog, and avoid fetching actual data, we use this: master_exec( 'cd /var/lib/postgresql && rsync --relative --archive ' '--exclude={version_from}/data/pg_wal --exclude={version_from}/data/conf.d/recovery.conf ' '--hard-links --size-only --no-inc-recursive {version_from}/data {version_to}/data root@[{replica}]:' '/var/lib/postgresql', {'replica': self.host_addrs.get(replica_fqdn, replica_fqdn)}, ) this should bring only a new catalog to replica, avoiding copying hard links. So, is all of this just a built-in analog for rsync with params? It would be more safe I guess , but the cost of maintaining this in-core, is it really worth it? -- Best regards, Kirill Reshke
