From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LOCK DATABASE |
Date: | 2011-05-19 19:32:57 |
Message-ID: | BANLkTimxJnboQjMQw=c-+D0aNswEDFXgQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-19 19:53:12 | Re: switch UNLOGGED to LOGGED |
Previous Message | Noah Misch | 2011-05-19 19:24:38 | Re: switch UNLOGGED to LOGGED |