Re: pg_upgrade using appname to lock out other users

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > 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.
> 
> I am confused as to the point of allowing checks to be done on a "live"
> server.  Presumably, whatever you are checking could be invalidated as
> soon as you turn your back, so the checks have to be done again anyway
> as soon as you shut the old server down.  So while there might be a
> use-case for a "check" mode against the existing server, there isn't any
> need to combine that with checking the new server in the same run.

Right, we will re-check at the time they do the actual upgrade.  This
was requested so people can prepare for the real upgrade without having
to stop their live server.  You do need to check the old and new servers
in the same pg_upgrade run to make sure their values match, like
pg_controldata.  This was particularly useful for the 8.3 to 8.4
upgrades where we checked for imcompatible indexes, etc, and is useful
for checking that all the contrib shared objects are in place in the new
server, etc.  I guess we could check many of them without starting the
new server, but there are some that need it, so we just start it and do
a full check.

> Furthermore, ISTM that there isn't any need to be running both servers
> at once --- and, indeed, in entirely-plausible configurations you won't
> be *able* to do that because of SHMMAX; so pg_upgrade must not depend on
> being able to do so.

Again, this happens with --check on a live server, as outlined above.

> So on the whole I don't see the reason why two port numbers would be
> needed.  Just run the two servers serially on a single nondefault port
> number.

See above.

Requiring old and new port numbers, and the documentation wasn't as bad
as I thought.  Patch attached for review.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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