Re: LOCK DATABASE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: LOCK DATABASE
Date
Msg-id BANLkTik_8-93QZp9nD+iVCx5ODBzjT_BTA@mail.gmail.com
Whole thread Raw
In response to Re: LOCK DATABASE  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: LOCK DATABASE  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
<alvherre@commandprompt.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, I don't intend to lock "everything except the present connection".
> The only thing this LOCK DATABASE does is prevent the establishment of
> new connections.  Existing connections can continue to exist and work.
> So you do the LOCK DATABASE, then boot whoever shouldn't be allowed
> (which is a separate step that needs to be taken), then do your deed.
> If you want the slon connections to persist, just don't terminate them.

This strikes me as a hack.  First, it's completely inconsistent with
how we lock tables or rows.  A lock means you are the only one
accessing an object, not just that new accesses are locked out.
Second, it relies on the fact that a new connection briefly grabs a
lock on the database that is then released.  If we happened (for
whatever reason) to want to change that to a session lock, or get rid
of it entirely, then this would break.

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


pgsql-hackers by date:

Previous
From: Leonardo Francalanci
Date:
Subject: Re: switch UNLOGGED to LOGGED
Next
From: Robert Haas
Date:
Subject: Re: DOMAINs and CASTs