Re: LOCK DATABASE
От | Robert Haas |
---|---|
Тема | Re: LOCK DATABASE |
Дата | |
Msg-id | BANLkTik_8-93QZp9nD+iVCx5ODBzjT_BTA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LOCK DATABASE (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: LOCK DATABASE
|
Список | pgsql-hackers |
On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: >> 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. Why? I don't really see why this sucks. > Well, I don't intend to lock "everything except the present connection". > The only thing this LOCK DATABASE does is prevent the establishment of > new connections. Existing connections can continue to exist and work. > So you do the LOCK DATABASE, then boot whoever shouldn't be allowed > (which is a separate step that needs to be taken), then do your deed. > If you want the slon connections to persist, just don't terminate them. This strikes me as a hack. First, it's completely inconsistent with how we lock tables or rows. A lock means you are the only one accessing an object, not just that new accesses are locked out. Second, it relies on the fact that a new connection briefly grabs a lock on the database that is then released. If we happened (for whatever reason) to want to change that to a session lock, or get rid of it entirely, then this would break. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: