Robert Haas wrote: > > Also, a standalone backend does not have libpq either so how do you get > > values into application variables? ?Parse the text output? ?That seems > > like a much larger kludge. > > Maybe we could do something like this. > > 1. pg_upgrade invokes the postmaster with --binary-upgrade=<port>:<password> > > 2. postmaster starts up into multi-user mode, but it does not start > autovacuum and ignores pg_hba.conf, listen_addresses, and port. > Instead it listens only on the localhost interface on the designated > port (perhaps the port can be a filename on systems that support UNIX > sockets, and it can listen only on a UNIX socket at that location > instead). It refuses all connections except for those that attempt to > log in with binary_upgrade as the user and the given password as the > password. pg_upgrade will randomly generate a password (like > C51622FA-7513-4300-A4B7-6423769276F8) and port number at the start of > each run, and use that for all connections to the postmaster.
I now believe we are overthinking all this. pg_upgrade has always supported specification of a port number. Why not just tell users to specify an unused port number > 1023, and not to use the default value? Both old and new clusters will happily run on any specified port number during the upgrade. This allows the lockout to work for both old and new clusters, which is better than enhancing -b because that will only be for > 9.1 servers. This requires no new backend code. We could even _require_ the port number to be specified in pg_upgrade. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
