Re: LOCK DATABASE

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: David Christensen <david(at)endpoint(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Subject: Re: LOCK DATABASE
Date: 2011-05-19 05:38:17
Message-ID: 201105190738.19649.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, May 19, 2011 06:55:36 AM David Christensen wrote:
> On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote:
> > Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400
2011:
> >> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova <jaime(at)2ndquadrant(dot)com>
wrote:
> >>> 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?
> >>
> >> There were multiple alternatives suggested, which is probably useful to
> >> outline.
> >>
> >> 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.
>
> How would this differ from just UPDATE pg_database SET datallowconn = FALSE
> for the databases in question?
Automated lock release on session end. Which imo is quite important...

andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sreekanth Polaka 2011-05-19 05:56:54 FW: issue building uuid-ossp on win32 with VS2005
Previous Message Alvaro Herrera 2011-05-19 05:34:11 Re: LOCK DATABASE