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.