Re: drop database command blocking other connections

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jim(at)contactbda(dot)com
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: drop database command blocking other connections
Date: 2006-05-03 18:23:08
Message-ID: 18093.1146680588@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim Buttafuoco" <jim(at)contactbda(dot)com> writes:
> from time to time I have to drop a very large database (1TB+). The drop database command takes a long time to complete
> while its deleting the files. During this time, no one can connect to the database server, ps displays "startup
> waiting". This is with Postgresql 7.4. Has this been addressed in 8.1, if not, does anyone have some ideas on how to
> speed this up.

No, it'll probably behave the same in CVS HEAD. The problem is that
DROP DATABASE has to lock out new connections to the victim database,
and the mechanism it's using for that is a table-level lock on
pg_database, rather than something specific to one database. So
new connections to *all* DBs in the cluster will be blocked while
DROP DATABASE runs.

It strikes me that we could fix this by taking out special locks on the
database as an object (using LockSharedObject) instead of relying on
locking pg_database. There wasn't any locktag convention that'd work
for that back in 7.4, but it surely seems doable now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-05-03 18:25:54 Re: patch review, please: Autovacuum/Vacuum times via stats.
Previous Message Larry Rosenman 2006-05-03 18:15:59 Re: sblock state on FreeBSD 6.1