Excerpts from Tom Lane's message of jue may 19 13:34:13 -0400 2011: > Alvaro Herrera <alvhe...@commandprompt.com> writes: > > Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011: > >> Second, it relies on the fact that a new connection briefly grabs a > >> lock on the database that is then released. > > > Yes. This is well known and it's not going away. > > >> 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. > > > That would break other things too, so I don't see it as a problem. > > I can't see getting rid of that lock, since we'd simply have to invent > some other interlock for new connections vs. DROP DATABASE. However, > I do think that we might sometime need to convert it to a session lock > that's held for the life of the backend. If this feature can't cope > with that, that'd be a potential problem.
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. -- Á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
