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