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 BANLkTim=9npb3DMMH2am=9EHBY=+UX50BA@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade using appname to lock out other users  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, Jun 15, 2011 at 1:13 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
>> <alvherre@commandprompt.com> wrote:
>
>> > 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?
>
> Well, something to use on shell scripts and the like first and foremost;
> see
> http://petereisentraut.blogspot.com/2010/03/running-sql-scripts-with-psql.html

I don't think there's anything wrong with using psql for running
scripts.  It might need some work and maybe some better flags, but I
don't think we need to throw it out wholesale.

What we do need for pg_upgrade is to build more of the logic into
either pg_upgrade itself or the server, so it's not spawning external
programs right and left.  It might help to "library"-ify some of the
functionality that's being used so that it can be invoked via a
function call rather than a shell exec.

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


pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: bad posix_fadvise support causes initdb to exit ungracefully
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade using appname to lock out other users