Re: pg_upgrade using appname to lock out other users

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade using appname to lock out other users
Date: 2011-06-16 17:32:31
Message-ID: BANLkTimihhqKxwvxr=DhWtJ5_WOsoxa22A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> I now believe we are overthinking all this.  pg_upgrade has always
> supported specification of a port number.  Why not just tell users to
> specify an unused port number > 1023, and not to use the default value?

1. Because it shouldn't be the user's problem to figure out a good
choice of port number.

2. Because we also really ought to be ignoring the contents of
pg_hba.conf during an upgrade, and instead have some mechanism that
allows pg_upgrade to be sure of getting in (without creating a
security hole in the process).

I agree that back-patching these changes wouldn't be a wonderful
thing, but we are going to do a lot more releases that have pg_upgrade
in them in the future than we've already done in the past. It's not a
bad thing to try to start improving on the basic mechanism, even if
takes a while for versions that support that mechanism to become
commonplace. Limiting what we're willing to do the server to improve
the pg_upgrade experience in the future to what we're willing to
back-patch is not going to be a winning strategy.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Ports 2011-06-16 17:33:56 Re: patch: update README-SSI
Previous Message Tom Lane 2011-06-16 17:25:05 Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch