Re: pg_upgrade using appname to lock out other users - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade using appname to lock out other users
Date
Msg-id 201106171311.p5HDBJL03832@momjian.us
Whole thread Raw
In response to Re: pg_upgrade using appname to lock out other users  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > > Robert Haas wrote:
> > >> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> > >> > probably only #1 is appropriate.)
> > >>
> > >> I don't like any of these options as well as what I already proposed.
> > >> I proposed a complicated approach that actually fixes the problem for
> > >> real; you're proposing a whole bunch of simpler approaches all of
> > >> which have pretty obvious holes. ?We already have something that only
> > >> sorta works; replacing it with a different system that only sorta
> > >> works is not going to be a great leap forward.
> > >
> > > What is your proposal? ?Write a password into a file that is read by the
> > > postmaster on startup and used for connections? ?That would remove the
> > > "modify pg_hba.conf to 'trust'" step, but again only for new servers.
> > 
> > Yeah, as noted upthread, I'd probably create a binary_upgrade.conf
> > that works like recovery.conf, if it were me.
> 
> Well, I know exactly where the data directories are.  We will still have
> a problem for anyone upgrading from pre-9.2.

We could go with the idea of documenting the suggestion of using unused
ports in pre-9.2 and use that file for 9.2.  We would still have to
mention the ports idea in 9.2 as well because of people upgrading from
pre-9.2.

We can have that file be read only in -b binary-upgrade mode so there is
little risk if the file accidentally isn't deleted.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: per-column generic option
Next
From: Alvaro Herrera
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY