On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>> I can't see getting rid of that lock, since we'd simply have to invent
>> some other interlock for new connections vs. DROP DATABASE. However,
>> I do think that we might sometime need to convert it to a session lock
>> that's held for the life of the backend. If this feature can't cope
>> with that, that'd be a potential problem.
>
> The following things acquire a lock on database:
>
> ALTER DATABASE SET
> ALTER DATABASE OWNER
> COMMENT ON DATABASE
>
> So as far as features that would cause a problem if we ever decide to
> take a lock on database for the duration of the whole session, this
> isn't the first one. We'd have to invent a fix for those other things
> anyway.
That's a bit of a self-defeating argument though, since it implies
that the effect of taking an exclusive lock via LockSharedObject()
will not simply prevent new backends from connecting, but rather will
also block any backends already in the database that try to perform
one of those operations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
