pg_upgrade defaulting to port 25432

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_upgrade defaulting to port 25432
Date: 2011-06-24 01:39:09
Message-ID: 201106240139.p5O1d9910794@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort. It's surely
> not bulletproof, since someone could intentionally connect to the actual
> port number, but getting to bulletproof is a lot more work than anyone
> seems to want to do right now. (And, as Bruce pointed out, no complete
> solution would be back-patchable anyway.)

I have created the following patch which uses 25432 as the default port
number for pg_upgrade. 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.

This will allow most users to use pg_upgrade without needing to specify
port parameters, and will prevent accidental connections. The user does
have to specify the port number for live checks, but that was always the
case because you have to use different port numbers for old/new in that
case. I updated the error message to be clearer about this.

The patch is small and might be possible for 9.1, except it changes
user-visible behavior, which would suggest it should be in 9.2, plus it
doesn't address a serious bug. Comments?

I will batckpatch a doc recommendation to use 25432 as a port number for
versions of pg_upgrade that don't get this patch.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Attachment Content-Type Size
/rtmp/pg_upgrade text/x-diff 7.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-24 02:02:07 Re: crash-safe visibility map, take five
Previous Message Robert Creager 2011-06-24 01:19:24 Re: [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD