On Tue, May 17, 2011 at 10:21 PM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
