Robert Haas wrote:
> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
