Robert Haas wrote: > On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian <br...@momjian.us> wrote: > > 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? > > 1. Because it shouldn't be the user's problem to figure out a good > choice of port number. > > 2. Because we also really ought to be ignoring the contents of > pg_hba.conf during an upgrade, and instead have some mechanism that > allows pg_upgrade to be sure of getting in (without creating a > security hole in the process). > > I agree that back-patching these changes wouldn't be a wonderful > thing, but we are going to do a lot more releases that have pg_upgrade > in them in the future than we've already done in the past. It's not a > bad thing to try to start improving on the basic mechanism, even if > takes a while for versions that support that mechanism to become > commonplace. Limiting what we're willing to do the server to improve > the pg_upgrade experience in the future to what we're willing to > back-patch is not going to be a winning strategy.
OK, well, we have three possible directions: 1. Just document that people should use -p and -P on unused ports to avoid user connections 2. Do #1 and also require -p and -P to be used (no defaults) 3. Have pg_upgrade default to use a typically unused port number, e.g. 25432 (on Unix, it might only be using unix domain sockets anyway) 4. Require appname to match 'binary-upgrade' when in -b (binary-upgrade) mode 5. Disable TCP when in -b mode on Unix (not possible on Windows) We can pick different options for 9.0, 9.1, and 9.2. (For PG 9.0 probably only #1 is appropriate.) FYI, pg_upgrade 9.1 will already lock out non-super users, but that doesn't lock out users from old pre-9.1 servers. So, these are all only a few lines of code --- we just need to figure out what we want. -- 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
