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
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-05-03 at 16:15 -0400, Tom Lane wrote:
If dropdb() takes such a lock before it checks for active
backends, then the connection sequence can look like this:
Many people never CREATE or DROP databases. They just do everything in
the default
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
The whole area is really pretty grotty anyway --- the existing interlock
does not prevent an incoming
It's slightly annoying to have to read the flat file twice, but
for reasonable numbers of databases per installation I don't think
this will pose any material performance penalty. The file will
certainly still be sitting in kernel disk cache.
Dropping a db isn't exactly a common occurrence
