On Thu, Jul 28, 2016 at 10:22 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > It might, actually. One approach for online upgrade is to: > > * pg_basebackup the master > * start the replica and let it catch up > * create a logical replication slot on the master > * replace the replication.conf on the basebackup so it stops recovery at the > lsn of the replication slot's confirmed_flush_lsn > * stop the replica and pg_upgrade it > * have the upgraded replica, now a master, replay from the old master over > logical replication > * once caught up, switch over > > This means a full dump and reload with a full rebuild of all indexes, etc, > isn't needed. All shared catalog stuff is copied (until we switch to logical > rep for the final catch-up).
This is a per-database logic to perform an upgrade of a single database, right? If a cluster has multiple databases you need one logical slot per database to complete an upgrade, which is where sync_synchronous_names which is able to take now multiple entries helps as well to ensure that the former master is in sync with the all the logical slots in place. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
