Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On m?n, 2011-06-27 at 14:34 -0400, Bruce Momjian wrote:
> > > Bruce Momjian wrote:
> > > > Robert Haas wrote:
> > > > > It's easier to read the patches if you do separate changes in separate
> > > > > patches. Anyway, I'm a bit nervous about this hunk:
> > > > >
> > > > > + if (old_cluster.port == DEF_PGUPORT)
> > > > > + pg_log(PG_FATAL, "When checking a live old
> > > > > server, "
> > > > > + "you must specify the old server's
> > > > > port number.\n");
> > > > >
> > > > > Is the implication here that I'm now going to need to specify more
> > > > > than 4 command-line options/environment variables for this to work?
> > > >
> > > > Yes, we don't inherit PGPORT anymore. Doing anything else was too
> > > > complex to explain in the docs.
> > >
> > > But only if you are running --check on a live server. Otherwise, we
> > > will just default to 50432 instead of 5432/PGPORT.
> >
> > "When checking a live server, the built-in default port number or the
> > value of the environment variable PGPORT is used. But when performing
> > an upgrade, a different port number is used by default, namely 50432,
> > which can be overridden XXX [how?]"
> >
> > Seems pretty clear to me, as long as that last bit is figured out.
>
> Not sure where you got that text --- I assume that was an old email. I
> decided it was too complex to have PGPORT be honoroed only if there is a
> live server, so I just always default to 50432 for both servers, and I
> added this error check:
>
> if (user_opts.check && is_server_running(old_cluster.pgdata))
> {
> *live_check = true;
> + if (old_cluster.port == DEF_PGUPORT)
> + pg_log(PG_FATAL, "When checking a live old server, "
> + "you must specify the old server's port number.\n");
>
> OK?
OK, seeing no replies, I have applied this patch to 9.2, and added
documentation to 9.0 and 9.1 suggesting using a non-default port number
to avoid unintended client connections --- 9.0/9.1 doc patch attached.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index b24c1e7..e4f90d9
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*************** gmake prefix=/usr/local/pgsql.new instal
*** 256,263 ****
so you might want to set authentication to <literal>trust</> in
<filename>pg_hba.conf</>, or if using <literal>md5</> authentication,
use a <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">)
! to avoid being prompted repeatedly for a password. Also make sure
! pg_upgrade is the only program that can connect to the clusters.
</para>
</step>
--- 256,262 ----
so you might want to set authentication to <literal>trust</> in
<filename>pg_hba.conf</>, or if using <literal>md5</> authentication,
use a <filename>~/.pgpass</> file (see <xref linkend="libpq-pgpass">)
! to avoid being prompted repeatedly for a password.
</para>
</step>
*************** pg_upgrade.exe
*** 336,341 ****
--- 335,343 ----
<para>
Obviously, no one should be accessing the clusters during the upgrade.
+ Consider using a non-default port number, e.g. 50432, for old
+ and new clusters to avoid unintended client connections during
+ the upgrade.
</para>
<para>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
