Re: pg_upgrade_replica: avoid full re-clone of standbys after pg_upgrade

On Tue, 8 Sept 2026 at 17:51, Marco Nenciarini
<marco(dot)nenciarini(at)enterprisedb(dot)com> wrote:
>
> v2 attached. Same design as v1, rebased on current master.

> On Tue, Aug 11, 2026 02:56 PM, Marco Nenciarini <marco(dot)nenciarini(at)enterprisedb(dot)com> 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(at)[{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