Re: [HACKERS] pg_upgrade defaulting to port 25432
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.ushttp://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 literaltrust/ in
filenamepg_hba.conf/, or if using literalmd5/ 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 literaltrust/ in
filenamepg_hba.conf/, or if using literalmd5/ 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
Re: [HACKERS] pg_upgrade defaulting to port 25432
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?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011: On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: You want the environment variable support removed? I don't. It's production usefulness is questionable, but it's quite handy for testing IMO. If that's what you want, I think being able to read a file (whose filename you pass with a switch to pg_upgrade) with a bunch of settings is even more convenient. Heck, maybe it's more convenient for the user too. If someone wants to do the work, I'm all in favor. But I don't feel that we should insist that Bruce do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Robert Haas wrote: On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011: On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: You want the environment variable support removed? I don't. ?It's production usefulness is questionable, but it's quite handy for testing IMO. If that's what you want, I think being able to read a file (whose filename you pass with a switch to pg_upgrade) with a bunch of settings is even more convenient. ?Heck, maybe it's more convenient for the user too. If someone wants to do the work, I'm all in favor. But I don't feel that we should insist that Bruce do it. Is there agreement to remove all pg_upgrade-specific environment variables? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011: On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: You want the environment variable support removed? I don't. ?It's production usefulness is questionable, but it's quite handy for testing IMO. If that's what you want, I think being able to read a file (whose filename you pass with a switch to pg_upgrade) with a bunch of settings is even more convenient. ?Heck, maybe it's more convenient for the user too. If someone wants to do the work, I'm all in favor. But I don't feel that we should insist that Bruce do it. Is there agreement to remove all pg_upgrade-specific environment variables? I'm not in favor of that unless we have a workable replacement for them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
\Robert Haas wrote: On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011: On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: You want the environment variable support removed? I don't. ?It's production usefulness is questionable, but it's quite handy for testing IMO. If that's what you want, I think being able to read a file (whose filename you pass with a switch to pg_upgrade) with a bunch of settings is even more convenient. ?Heck, maybe it's more convenient for the user too. If someone wants to do the work, I'm all in favor. ?But I don't feel that we should insist that Bruce do it. Is there agreement to remove all pg_upgrade-specific environment variables? I'm not in favor of that unless we have a workable replacement for them. OK, fair enough. Should I apply my ports patch to Postgres 9.2? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Robert Haas wrote:
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote:
OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are referring to.
This one which makes 50432 the default port.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
new file mode 100644
index 1ee2aca..5c5ce72
*** a/contrib/pg_upgrade/check.c
--- b/contrib/pg_upgrade/check.c
*** output_check_banner(bool *live_check)
*** 29,34
--- 29,37
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);
if (old_cluster.port == new_cluster.port)
pg_log(PG_FATAL, When checking a live server,
the old and new port numbers must be different.\n);
diff --git a/contrib/pg_upgrade/option.c b/contrib/pg_upgrade/option.c
new file mode 100644
index 4401a81..d29aad0
*** a/contrib/pg_upgrade/option.c
--- b/contrib/pg_upgrade/option.c
*** parseCommandLine(int argc, char *argv[])
*** 58,65
os_info.progname = get_progname(argv[0]);
/* Process libpq env. variables; load values here for usage() output */
! old_cluster.port = getenv(PGPORT) ? atoi(getenv(PGPORT)) : DEF_PGPORT;
! new_cluster.port = getenv(PGPORT) ? atoi(getenv(PGPORT)) : DEF_PGPORT;
os_user_effective_id = get_user_info(os_info.user);
/* we override just the database user name; we got the OS id above */
--- 58,65
os_info.progname = get_progname(argv[0]);
/* Process libpq env. variables; load values here for usage() output */
! old_cluster.port = getenv(PGPORTOLD) ? atoi(getenv(PGPORTOLD)) : DEF_PGUPORT;
! new_cluster.port = getenv(PGPORTNEW) ? atoi(getenv(PGPORTNEW)) : DEF_PGUPORT;
os_user_effective_id = get_user_info(os_info.user);
/* we override just the database user name; we got the OS id above */
*** parseCommandLine(int argc, char *argv[])
*** 203,215
}
/* Get values from env if not already set */
! check_required_directory(old_cluster.bindir, OLDBINDIR, -b,
old cluster binaries reside);
! check_required_directory(new_cluster.bindir, NEWBINDIR, -B,
new cluster binaries reside);
! check_required_directory(old_cluster.pgdata, OLDDATADIR, -d,
old cluster data resides);
! check_required_directory(new_cluster.pgdata, NEWDATADIR, -D,
new cluster data resides);
}
--- 203,215
}
/* Get values from env if not already set */
! check_required_directory(old_cluster.bindir, PGBINOLD, -b,
old cluster binaries reside);
! check_required_directory(new_cluster.bindir, PGBINNEW, -B,
new cluster binaries reside);
! check_required_directory(old_cluster.pgdata, PGDATAOLD, -d,
old cluster data resides);
! check_required_directory(new_cluster.pgdata, PGDATANEW, -D,
new cluster data resides);
}
*** For example:\n\
*** 254,270
or\n), old_cluster.port, new_cluster.port, os_info.user);
#ifndef WIN32
printf(_(\
! $ export OLDDATADIR=oldCluster/data\n\
! $ export NEWDATADIR=newCluster/data\n\
! $ export OLDBINDIR=oldCluster/bin\n\
! $ export NEWBINDIR=newCluster/bin\n\
$ pg_upgrade\n));
#else
printf(_(\
! C:\\ set OLDDATADIR=oldCluster/data\n\
! C:\\ set NEWDATADIR=newCluster/data\n\
! C:\\ set OLDBINDIR=oldCluster/bin\n\
! C:\\ set NEWBINDIR=newCluster/bin\n\
C:\\ pg_upgrade\n));
#endif
printf(_(\nReport bugs to pgsql-b...@postgresql.org.\n));
--- 254,270
or\n), old_cluster.port, new_cluster.port, os_info.user);
#ifndef WIN32
printf(_(\
! $ export PGDATAOLD=oldCluster/data\n\
! $ export PGDATANEW=newCluster/data\n\
! $ export PGBINOLD=oldCluster/bin\n\
! $ export PGBINNEW=newCluster/bin\n\
$ pg_upgrade\n));
#else
printf(_(\
! C:\\ set PGDATAOLD=oldCluster/data\n\
! C:\\ set PGDATANEW=newCluster/data\n\
! C:\\ set PGBINOLD=oldCluster/bin\n\
! C:\\ set PGBINNEW=newCluster/bin\n\
C:\\ pg_upgrade\n));
#endif
printf(_(\nReport bugs to pgsql-b...@postgresql.org.\n));
diff --git a/contrib/pg_upgrade/pg_upgrade.h b/contrib/pg_upgrade/pg_upgrade.h
new file mode 100644
index 613ddbd..4729ac3
*** a/contrib/pg_upgrade/pg_upgrade.h
--- b/contrib/pg_upgrade/pg_upgrade.h
***
*** 15,20
--- 15,23
#include libpq-fe.h
+ /* Use port in the private/dynamic port number range */
+ #define DEF_PGUPORT 50432
+
/* Allocate for null byte */
#define USER_NAME_SIZE 128
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index b24c1e7..aa633e2
*** a/doc/src/sgml/pgupgrade.sgml
---
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Robert Haas wrote: On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. 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. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 2:27 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. 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. Seems like a usability regression. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Bruce Momjian wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. 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. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Mon, Jun 27, 2011 at 2:34 PM, Bruce Momjian br...@momjian.us wrote: Bruce Momjian wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian br...@momjian.us wrote: Robert Haas wrote: On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian br...@momjian.us wrote: OK, fair enough. ?Should I apply my ports patch to Postgres 9.2? I'm not sure which patch you are referring to. This one which makes 50432 the default port. There appear to be some other changes mixed into this patch. The additional changes were to have the existing environment variables begin with PG, as requested. 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. Oh... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On fre, 2011-06-24 at 19:47 -0400, Bruce Momjian wrote: I'm wondering why pg_upgrade needs environment variables at all. It's a one-shot operation. Environment variables are typically used to shared default settings across programs. I don't see how that applies here. They were there in the original EnterpriseDB code, Well, the original code wasn't the most stellar example of user interface engineering, as we have found out over time. ;-) and in some cases like PGPORT, we _used_ those environment variables. Right, and I don't mind using *shared* environment variables for common settings, when appropriate. But in some cases, as you remember, we had to work around them or disable them because environment variables essentially leave traps lying around. So now we are about to create even more traps. Also, the command-line can get pretty long so we actually illustrate environment variable use in its --help: For example: pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin or $ export OLDDATADIR=oldCluster/data $ export NEWDATADIR=newCluster/data $ export OLDBINDIR=oldCluster/bin $ export NEWBINDIR=newCluster/bin $ pg_upgrade I don't see how that makes it better, except that it's somehow prettier perhaps. There are a lot of programs out there with lots of options. I have never seen one that creates one-shot environment variables to make it easier to invoke. In the above case, you create a bunch of traps. If the user abandons the attempt to run pg_upgrade but leaves the shell open, comes back at some other time (or, say, someone else who also logs into the shared postgres account), and runs just pg_upgrade for lack of a better idea or forgets an option, a destructive operation might start. Yes, they are stupid and it's their fault and there are other ways to break things, but pg_upgrade is already tricky enough, we don't need to add more hidden ways to break it. (Besides, the above isn't even a portable way to set environment variables. You need to run the assignment and the export separately.) You want the environment variable support removed? Well, it might be difficult to get consensus on that. I would argue that we don't need to add new ones for a marginal operation like the pg_upgrade check mode. On the other hand, a way to permanently override the new upgrade port you are working on might be useful. It's not clear from the patch how to do that, actually. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Peter Eisentraut wrote: In the above case, you create a bunch of traps. If the user abandons the attempt to run pg_upgrade but leaves the shell open, comes back at some other time (or, say, someone else who also logs into the shared postgres account), and runs just pg_upgrade for lack of a better idea or forgets an option, a destructive operation might start. Yes, they are stupid and it's their fault and there are other ways to break things, but pg_upgrade is already tricky enough, we don't need to add more hidden ways to break it. (Besides, the above isn't even a portable way to set environment variables. You need to run the assignment and the export separately.) True. You want the environment variable support removed? Well, it might be difficult to get consensus on that. I would argue that we don't need to add new ones for a marginal operation like the pg_upgrade check mode. Well, hard to make any changes without consensus. None of these variables are check-mode only. On the other hand, a way to permanently override the new upgrade port you are working on might be useful. It's not clear from the patch how to do that, actually. That's because the flags to control the port numbers were already there; I only changed pg_upgrade to use new environment variables and changed their defaults to 50234, and no longer use PGPORT so I don't import the runtime port number. I think that is why it seems unclear. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011: On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: You want the environment variable support removed? I don't. It's production usefulness is questionable, but it's quite handy for testing IMO. If that's what you want, I think being able to read a file (whose filename you pass with a switch to pg_upgrade) with a bunch of settings is even more convenient. Heck, maybe it's more convenient for the user too. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On tor, 2011-06-23 at 21:39 -0400, Bruce Momjian wrote: I have created the following patch which uses 25432 as the default port number for pg_upgrade. I don't think we should just steal a port from the reserved range. Picking a random port from the private/dynamic range seems more appropriate. It also creates two new environment variables, OLDPGPORT and NEWPGPORT, to control the port values because we don't want to default to PGPORT anymore. I would prefer that all PostgreSQL-related environment variables start with PG. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Fri, Jun 24, 2011 at 9:04 AM, Peter Eisentraut pete...@gmx.net wrote: It also creates two new environment variables, OLDPGPORT and NEWPGPORT, to control the port values because we don't want to default to PGPORT anymore. I would prefer that all PostgreSQL-related environment variables start with PG. +1 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Peter Eisentraut wrote:
On tor, 2011-06-23 at 21:39 -0400, Bruce Momjian wrote:
I have created the following patch which uses 25432 as the default port
number for pg_upgrade.
I don't think we should just steal a port from the reserved range.
Picking a random port from the private/dynamic range seems more
appropriate.
Oh, I didn't know about that. I will use 50432 instead.
It also creates two new environment variables,
OLDPGPORT and NEWPGPORT, to control the port values because we don't
want to default to PGPORT anymore.
I would prefer that all PostgreSQL-related environment variables start
with PG.
OK, attached. I was also using environment variables for PGDATA and
PGBIN do I renamed those too to begin with 'PG'.
Patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
new file mode 100644
index 1ee2aca..5c5ce72
*** a/contrib/pg_upgrade/check.c
--- b/contrib/pg_upgrade/check.c
*** output_check_banner(bool *live_check)
*** 29,34
--- 29,37
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);
if (old_cluster.port == new_cluster.port)
pg_log(PG_FATAL, When checking a live server,
the old and new port numbers must be different.\n);
diff --git a/contrib/pg_upgrade/option.c b/contrib/pg_upgrade/option.c
new file mode 100644
index 4401a81..d29aad0
*** a/contrib/pg_upgrade/option.c
--- b/contrib/pg_upgrade/option.c
*** parseCommandLine(int argc, char *argv[])
*** 58,65
os_info.progname = get_progname(argv[0]);
/* Process libpq env. variables; load values here for usage() output */
! old_cluster.port = getenv(PGPORT) ? atoi(getenv(PGPORT)) : DEF_PGPORT;
! new_cluster.port = getenv(PGPORT) ? atoi(getenv(PGPORT)) : DEF_PGPORT;
os_user_effective_id = get_user_info(os_info.user);
/* we override just the database user name; we got the OS id above */
--- 58,65
os_info.progname = get_progname(argv[0]);
/* Process libpq env. variables; load values here for usage() output */
! old_cluster.port = getenv(PGPORTOLD) ? atoi(getenv(PGPORTOLD)) : DEF_PGUPORT;
! new_cluster.port = getenv(PGPORTNEW) ? atoi(getenv(PGPORTNEW)) : DEF_PGUPORT;
os_user_effective_id = get_user_info(os_info.user);
/* we override just the database user name; we got the OS id above */
*** parseCommandLine(int argc, char *argv[])
*** 203,215
}
/* Get values from env if not already set */
! check_required_directory(old_cluster.bindir, OLDBINDIR, -b,
old cluster binaries reside);
! check_required_directory(new_cluster.bindir, NEWBINDIR, -B,
new cluster binaries reside);
! check_required_directory(old_cluster.pgdata, OLDDATADIR, -d,
old cluster data resides);
! check_required_directory(new_cluster.pgdata, NEWDATADIR, -D,
new cluster data resides);
}
--- 203,215
}
/* Get values from env if not already set */
! check_required_directory(old_cluster.bindir, PGBINOLD, -b,
old cluster binaries reside);
! check_required_directory(new_cluster.bindir, PGBINNEW, -B,
new cluster binaries reside);
! check_required_directory(old_cluster.pgdata, PGDATAOLD, -d,
old cluster data resides);
! check_required_directory(new_cluster.pgdata, PGDATANEW, -D,
new cluster data resides);
}
*** For example:\n\
*** 254,270
or\n), old_cluster.port, new_cluster.port, os_info.user);
#ifndef WIN32
printf(_(\
! $ export OLDDATADIR=oldCluster/data\n\
! $ export NEWDATADIR=newCluster/data\n\
! $ export OLDBINDIR=oldCluster/bin\n\
! $ export NEWBINDIR=newCluster/bin\n\
$ pg_upgrade\n));
#else
printf(_(\
! C:\\ set OLDDATADIR=oldCluster/data\n\
! C:\\ set NEWDATADIR=newCluster/data\n\
! C:\\ set OLDBINDIR=oldCluster/bin\n\
! C:\\ set NEWBINDIR=newCluster/bin\n\
C:\\ pg_upgrade\n));
#endif
printf(_(\nReport bugs to pgsql-b...@postgresql.org.\n));
--- 254,270
or\n), old_cluster.port, new_cluster.port, os_info.user);
#ifndef WIN32
printf(_(\
! $ export PGDATAOLD=oldCluster/data\n\
! $ export PGDATANEW=newCluster/data\n\
! $ export PGBINOLD=oldCluster/bin\n\
! $ export PGBINNEW=newCluster/bin\n\
$ pg_upgrade\n));
#else
printf(_(\
! C:\\ set PGDATAOLD=oldCluster/data\n\
! C:\\ set PGDATANEW=newCluster/data\n\
! C:\\ set PGBINOLD=oldCluster/bin\n\
! C:\\ set PGBINNEW=newCluster/bin\n\
C:\\ pg_upgrade\n));
#endif
printf(_(\nReport bugs to pgsql-b...@postgresql.org.\n));
diff --git a/contrib/pg_upgrade/pg_upgrade.h b/contrib/pg_upgrade/pg_upgrade.h
new
Re: [HACKERS] pg_upgrade defaulting to port 25432
On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote: It also creates two new environment variables, OLDPGPORT and NEWPGPORT, to control the port values because we don't want to default to PGPORT anymore. I would prefer that all PostgreSQL-related environment variables start with PG. OK, attached. I was also using environment variables for PGDATA and PGBIN do I renamed those too to begin with 'PG'. I'm wondering why pg_upgrade needs environment variables at all. It's a one-shot operation. Environment variables are typically used to shared default settings across programs. I don't see how that applies here. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
Peter Eisentraut wrote: On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote: It also creates two new environment variables, OLDPGPORT and NEWPGPORT, to control the port values because we don't want to default to PGPORT anymore. I would prefer that all PostgreSQL-related environment variables start with PG. OK, attached. I was also using environment variables for PGDATA and PGBIN do I renamed those too to begin with 'PG'. I'm wondering why pg_upgrade needs environment variables at all. It's a one-shot operation. Environment variables are typically used to shared default settings across programs. I don't see how that applies here. They were there in the original EnterpriseDB code, and in some cases like PGPORT, we _used_ those environment variables. Also, the command-line can get pretty long so we actually illustrate environment variable use in its --help: For example: pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin or $ export OLDDATADIR=oldCluster/data $ export NEWDATADIR=newCluster/data $ export OLDBINDIR=oldCluster/bin $ export NEWBINDIR=newCluster/bin $ pg_upgrade You want the environment variable support removed? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade defaulting to port 25432
On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian br...@momjian.us wrote: Peter Eisentraut wrote: On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote: It also creates two new environment variables, OLDPGPORT and NEWPGPORT, to control the port values because we don't want to default to PGPORT anymore. I would prefer that all PostgreSQL-related environment variables start with PG. OK, attached. I was also using environment variables for PGDATA and PGBIN do I renamed those too to begin with 'PG'. I'm wondering why pg_upgrade needs environment variables at all. It's a one-shot operation. Environment variables are typically used to shared default settings across programs. I don't see how that applies here. They were there in the original EnterpriseDB code, and in some cases like PGPORT, we _used_ those environment variables. Also, the command-line can get pretty long so we actually illustrate environment variable use in its --help: For example: pg_upgrade -d oldCluster/data -D newCluster/data -b oldCluster/bin -B newCluster/bin or $ export OLDDATADIR=oldCluster/data $ export NEWDATADIR=newCluster/data $ export OLDBINDIR=oldCluster/bin $ export NEWBINDIR=newCluster/bin $ pg_upgrade You want the environment variable support removed? I don't. It's production usefulness is questionable, but it's quite handy for testing IMO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
