Excerpts from Robert Haas's message of jue may 19 15:32:57 -0400 2011: > On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
> > The following things acquire a lock on database: > > > > ALTER DATABASE SET > > ALTER DATABASE OWNER > > COMMENT ON DATABASE > > > > So as far as features that would cause a problem if we ever decide to > > take a lock on database for the duration of the whole session, this > > isn't the first one. We'd have to invent a fix for those other things > > anyway. > > That's a bit of a self-defeating argument though, since it implies > that the effect of taking an exclusive lock via LockSharedObject() > will not simply prevent new backends from connecting, but rather will > also block any backends already in the database that try to perform > one of those operations. Well, the database that holds the lock is going to be able to run them, which makes sense -- and you probably don't want others doing it, which also does. I mean other backends are still going to be able to run administrative tasks like slon and so on, just not modifying the database. If they want to change the comments they can do so after you're done with your lock. Tom has a point though and so does Chris. I'm gonna put this topic to sleep though, 'cause I sure don't want to be seen like I'm proposing a connection pooler in the backend. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
