Re: pg_upgrade using appname to lock out other users
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-06-15T17:26:18Z
Lists: 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