Re: Rethinking locking for database create/drop vs - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Rethinking locking for database create/drop vs
Date
Msg-id 1146728655.449.222.camel@localhost.localdomain
Whole thread Raw
In response to Rethinking locking for database create/drop vs connection startup  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rethinking locking for database create/drop vs connection startup
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: Revised R* tree using GiST
Next
From: Simon Riggs
Date:
Subject: Re: Typo in ginxlog.c