On Thu, Mar 11, 2021 at 08:01:24PM -0500, Stephen Frost wrote: > > 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. > > What I typically do in that case is just spin up more replicas and let > those handle the read load while the upgrade happens, and then throw > them away after the upgrade of the primary plus the other standbys is > done. I do agree that logical replication could be an alternative but > that takes a lot longer and puts a number of constraints on what you can > do while it's going on (DDL changes and such have to be done carefully, > etc). Agreed. He/she could use some replicas to take read-only traffic while the upgrade happens, and use others to do a quick rsync upgrade using the intructions in the pg_upgrade docs. I agree logical replication is a lot more complex. > > > unlogged tables before the pg_upgrade, et al, otherwise you'll end up > > > rsync'ing those over. Also make sure you haven't got any stray or > > > forgotten temp files or other things. Again, done properly, the rsync > > > to upgrade the standbys should only be copying the catalog tables > > > themselves and it should be quite fast. > > > > Yes, good points. > > Yeah.. Would really be nice if we had a custom written tool which knew > how to detect unlogged tables and not try to copy them over and such. > Might be able to make something that's faster and less error-prone than > the rsync approach since we know a lot more about the PG data dir than > rsync does. True. -- Bruce Momjian <bruce@xxxxxxxxxx> https://momjian.us EDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
