Re: LOCK DATABASE

On Thu, May 19, 2011 at 12:57 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
>> On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
>> <alvherre(at)commandprompt(dot)com> wrote:
>> >> 1.  I suggested that this looks a lot like the controls of pg_hba.conf
>> >>
>> >> When our DBAs are doing major management of replication, they are
>> >> known to reconfigure pg_hba.conf to lock out all users save for the
>> >> one used by Slony.
>> >
>> > Yeah, I mentioned this but I think it actually sucks.
>>
>> Why?  I don't really see why this sucks.
>
> Well, firstly because you need to involve the sysadmin to be able to
> write the file.  (If you're considering a proposal to move adminpack
> into core, I recommend caution.)  Second, because then the database
> owner can't do it.  Third, because the business of having to
> programatically edit files is a pain in the butt.  Fourth, it doesn't
> fix itself it something goes wrong.

I suggest a further different option, namely that perhaps we need to
have more about session management alongside the backend. The
"loosey-goosey" characterization would be "integrate pgbouncer into
core".

If we have some mass session/connection management alongside the
database, then that enables managing connections en masse.

Today, the "right way" involves "install pgbouncer, pgpool, or some
connection pool manager." I know there was discussion of doing
something like this a couple years back; I wonder if it's time to
consider that again.

Integrating in a connection manager seems more useful than "lock database"...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"