On Tue, May 17, 2011 at 10:21 PM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
>
> So we would have a new command LOCK DATABASE [FOR SESSION] or something
> like that; the pooler software would call that and then kill other
> existing application connections (using pg_terminate_backend() perhaps),
> then drop the database. This LOCK DATABASE thingy would just be a
> simple function on top of LockSharedObject. Since establishing a new
> connection requires grabbing a lock on the database via
> LockSharedObject, things would Just Work (or at least so it seems to
> me).
>
> UNLOCK DATABASE would be needed to release a session-level lock acquired
> by LOCK DATABASE FOR SESSION for the cases where you want to lock a
> database to safely do schema upgrades and the like.
>
So we the lock will be released at end of the session or when the
UNLOCK DATABASE command is invoked, right?
A question: why will we beign so rude by killing other sessions
instead of avoid new connections and wait until the current sessions
disconnect?
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
