Re: LOCK DATABASE
От | David Christensen |
---|---|
Тема | Re: LOCK DATABASE |
Дата | |
Msg-id | CF8590A7-1BCC-450A-98A7-4042C9F957F8@endpoint.com обсуждение исходный текст |
Ответ на | Re: LOCK DATABASE (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: LOCK DATABASE
Re: LOCK DATABASE |
Список | pgsql-hackers |
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@2ndquadrant.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? Regards, David -- David Christensen End Point Corporation david@endpoint.com
В списке pgsql-hackers по дате отправления: