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

From Robert Haas
Subject Re: pg_upgrade using appname to lock out other users
Date
Msg-id BANLkTinxjccckPbJUv=09Ykm66P6zMzJGw@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade using appname to lock out other users  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: pg_upgrade using appname to lock out other users
List pgsql-hackers
On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> Seems good, except that passing the password as a command line argument
> is obviously broken from a privacy perspective -- anyone could see the
> process list and get it.  Maybe have postmaster ask for it on startup
> somehow, or have pg_upgrade write it in a file which is read by
> postmaster.

Writing it to a file which is ready by postmaster seems promising.
Then you wouldn't even need a command line option; you could just have
the postmaster write out binary_upgrade.conf and have that work like
recovery.conf to trigger the system to start up in a different mode.

>> As a separate issue, I tend to agree with Tom that using psql as part
>> of the pg_upgrade process is a lousy idea and we need a better
>> solution.  But let's fix one thing at a time.
>
> Agreed on both counts ... but ... does this mean that we need a
> different program for programmable tasks as opposed to interactive
> ones?  Dealing with standalone backends *is* a pain, that's for sure.

I'm not sure exactly what is needed here - what programmable tasks are
you thinking of, other than pg_upgrade?

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


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: procpid?
Next
From: Tom Lane
Date:
Subject: Re: pg_upgrade using appname to lock out other users