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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
