Re: pg_upgrade using appname to lock out other users

Tom Lane wrote:
> Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort. It's surely
> not bulletproof, since someone could intentionally connect to the actual
> port number, but getting to bulletproof is a lot more work than anyone
> seems to want to do right now. (And, as Bruce pointed out, no complete
> solution would be back-patchable anyway.)

I have researched this and need feedback. Initially I wanted to use a
single -p port flag to be used by the old and new clusters. However,
pg_upgrade allows --check mode while the old server is running, so we
need to allow you to use the current old postmaster port number and a
different port number to test the new server. That kills the idea of
using a single -p flag, so -p and -P are needed.

So, do we allow -p and -P to default to DEF_PORT or PGPORT? For the
live server check, that would be nice, but for the other cases we
probably need a different port number. This does mean that for the most
common use case they will be specifying the same port number for -p and
-P, except for a live check. I am guessing we don't want any port
number defaults. People are going to think it is odd to have to supply
the same port number for -p and -P.

We could allow -P to default to -p when not doing a check, but that
seems confusing. Do we want -P to only be used in --check mode? That
seems confusing too -- that would mean -p is the old server in --check
mode, and the old and new server in non-check mode.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +