Re: Streaming replication upgrade sanity check

> 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.