Tom Lane wrote: > I think it's important to be able to run pg_upgrade with the > postmaster shut down. Otherwise there is too much risk that some > other user will change the database while we are working. The > original pg_upgrade script left it to the DBA to ensure this wouldn't > happen, but that seems like a foot-gun of much too large caliber. > Instead, all operations should be done through a standalone backend. > An additional advantage of doing it this way is that a standalone > backend is implicitly superuser, and so no SQL permissions issues > will get in the way.
This would also be a nice solution for people who want a standalone, server-less database system. But for the purpose of pg_upgrade it seems like a lot of work for what could just be a magic switch in the postmaster to really kick everyone else out. > What about migrating config files? In particular, changes in names > or semantics of pre-existing config vars seem like a big issue. > First cut: just copy the files. > Second cut: extract non-default values from old file, insert into > new file (so as to preserve comments about variables that didn't > exist in old version). > We could imagine adding smarts about specific variable names here, > if particular variables change in ways that we can deal with > specially. I would be very careful about making too many smart guesses when upgrading configuration files. This can get really annoying for users who expect it to behave just a little bit differently. Or you get conflicts of authority with packaging tools. Making adjustments because of syntax or name changes is OK, but everything else must be evaluated carefully. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
