On Thu, Jul 28, 2016 at 09:22:17AM +0800, Craig Ringer 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).
Right, using pg_upgrade as part of a logical upgrade procedure makes sense. I was referring to having pg_upgrade --online do all of those bullets plus what is does now --- that just seems like it would fail as too complex, and if someone wanted to do just pg_upgrade without the logical, the manual page would be incomprehensible. In summary, I think we need to keep pg_upgrade doing what it does well, and come up with another tool that does those bullets. Heck, people already can't find --link. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
