> He/she wants to run the standby, I guess in read-only mode, while > pg_upgrade is running, which is why I didn't even bother to mention > that. I think if downtime is the critical for this person, he/she > should be using logical replication for the upgrade. pg_upgrade really > wants full control of the primary/standbys during its operation, and if > you can't do that, pg_upgrade is not the right tool to use. This thread blew up a bit overnight, so I guess I might be getting a bit repetitive, but it's less about super low downtime and more about just not having all that much control over everything. The systems are installed all over the world, and the upgrade process is very solid and well understood (by my client's devs), but it's pretty reliant on the main database being running, and also standby systems are fairly independent, so doing a lot of coordination is somewhere between complicated and maybe not entirely possible. I do just want to clarify the bit about pg_upgrade wanting full control over standbys. I'm looking over the page again, and it does list some prereqs to make sure things will run smoothly on the standby, but if I do just abandon the standby systems and do a new pg_basebackup on them once the master is running again, that's not going to cause any issues on the master, right? I haven't had any explosions in testing, but none of my test systems are anywhere near as large or busy as the larger customers, so I definitely could be missing things.
