Bruce, * Bruce Momjian (br...@momjian.us) wrote: > > In any case, of course, if we're able to move part of what pg_upgrade > > does to be while the old server is online then that takes whatever the > > cost of that is out of the downtime window. The question is if that's a > > 5% improvement in the overall performance of pg_upgrade or a 70% one. > > This will be case-by-case, of course, but if, in the best-case, we only > > get a 5% improvement then this might not be worth the risk. > > Yes, and who is going to know if they have a setup where the more > complex API is worth it? pg_upgrade is already complex enough to use.
Sure, but the solution there is really to make pg_upgrade simpler to use, even as we add these more complicated APIs to it. What that likely means in practical terms is that we have another utility, which uses pg_upgrade underneath, that you're able to configure to know about your existing cluster and the version of PG you want to upgrade to and where you want it and if you want a copy or if hard-links are ok, etc. Having such a tool is actually what I'd been hoping would come out of the documented process for doing a "pg_upgrade" on replicas that's currently in our documentation. That's not happened yet, but it's something that David Steele and I have been chatting about because the procedure in the documentation is terribly difficult and dangerous for those who aren't as familiar with the system. Perhaps we could have one tool that handles both the more complicated pg_upgrade API and deals with upgrading replicas. Alternatively, we could have a config file for pg_upgrade instead which might be a simpler way for people to describe exactly their current configuration and what they'd like to go to. Upgrading replicas involves using something like SSH though.. Thanks! Stephen
signature.asc
Description: Digital signature
