Re: pg_upgrade using appname to lock out other users - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade using appname to lock out other users
Date
Msg-id 14366.1308193003@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade using appname to lock out other users  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_upgrade using appname to lock out other users
List pgsql-hackers
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.

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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: Boolean operators without commutators vs. ALL/ANY)
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade using appname to lock out other users