Re: Rethinking locking for database create/drop vs

On Wed, 2006-05-03 at 16:15 -0400, Tom Lane wrote:
> This is motivated by Jim Buttafuoco's recent gripe about not being
> able to connect while a DROP DATABASE is in progress:
> http://archives.postgresql.org/pgsql-hackers/2006-05/msg00074.php

...

> If dropdb() takes such a lock before it checks for active
> backends, then the connection sequence can look like this:
>
> 1. read pg_database flat file to find out OID of target DB
> 2. initialize far enough to be able to start a transaction,
> and do so
> 3. take a shared lock on the target DB by OID
> 4. re-read pg_database flat file and verify DB still exists

Many people never CREATE or DROP databases. They just do everything in
the default database (name is release dependent) - at least on their
main system(s). It would be valid to optimize for that case.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com