Re: pg_upgrade using appname to lock out other users

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade using appname to lock out other users
Date: 2011-06-16 02:56:43
Message-ID: 14366.1308193003@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-06-16 03:04:32 Re: pg_upgrade using appname to lock out other users
Previous Message Tom Lane 2011-06-16 02:19:47 Re: [WIP] Support for "ANY/ALL(array) op scalar" (Was: Re: Boolean operators without commutators vs. ALL/ANY)