On Fri, Feb 17, 2023 at 10:32 PM Jeff Davis <pg...@j-davis.com> wrote: > Thinking about this more, it's not clear to me if this would be in > scope for pg_upgrade or not. If pg_upgrade is fixing up the new cluster > rather than checking for compatibility, why doesn't it just take over > and do the initdb for the new cluster itself? That would be less > confusing for users, and avoid some weirdness (like, if you drop the > database "postgres" on the original, why does it reappear after an > upgrade?). > > Someone might want to do something interesting to the new cluster > before the upgrade, but it's not clear from the docs what would be both > useful and safe.
I agree with all of this. I think it would be fantastic if pg_upgrade did the initdb itself. It would be simple to make this optional behavior, too: if the destination directory does not exist or is empty, initdb into it, otherwise skip that. That might be too automagical, so we could add add a --no-initdb option. If not specified, the destination directory must either not exist or be empty; else it must exist and look like a data directory. I completely concur with the idea that doing something with the new cluster before the upgrade is weird, and I don't think we should encourage people to do it. Nevertheless, as the threads to which Justin linked probably say, I'm not sure that it's a good idea to completely slam the door shut on that option. If we did want to move in that direction, though, having pg_upgrade do the initdb would be an excellent first step. We could at some later time decide to remove the --no-initdb option; or maybe we'll decide that it's good to keep it for emergencies, which is my present bias. In any event, the resulting system would be more usable and less error-prone than what we have today. -- Robert Haas EDB: http://www.enterprisedb.com
