Re: 7.3.3 drop table takes very long time

I restarted Postgres and it dropped in a second or 2. I can't believe I
didn't think of trying that before.
Thanks for all the help.

>From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
>CC: Mike Mascari <mascarm(at)mascari(dot)com>, Eric Freeman <ejf7(at)hotmail(dot)com>,
>pgsql-general(at)postgresql(dot)org
>Subject: Re: [GENERAL] 7.3.3 drop table takes very long time Date: Thu, 08
>Jan 2004 16:26:32 -0500
>Received: from mc12-f8.hotmail.com ([65.54.167.144]) by mc12-s4.hotmail.com
>with Microsoft SMTPSVC(5.0.2195.6824); Thu, 8 Jan 2004 13:31:21 -0800
>Received: from hosting.commandprompt.com ([207.173.200.216]) by
>mc12-f8.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 8 Jan 2004
>13:30:36 -0800
>Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])by
>hosting.commandprompt.com (8.11.6/8.11.6) with ESMTP id i08LRZk29714;Thu, 8
>Jan 2004 13:28:14 -0800
>Received: from localhost (neptune.hub.org [200.46.204.2])by
>svr1.postgresql.org (Postfix) with ESMTP id 20237D1B4AFfor
><pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu, 8 Jan 2004
>21:27:25 +0000 (GMT)
>Received: from svr1.postgresql.org ([200.46.204.71]) by localhost
>(neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id
>70015-01 for <pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org>; Thu,
>8 Jan 2004 17:26:36 -0400 (AST)
>Received: from sss.pgh.pa.us (unknown [192.204.191.242])by
>svr1.postgresql.org (Postfix) with ESMTP id A0509D1B48Afor
><pgsql-general(at)postgresql(dot)org>; Thu, 8 Jan 2004 17:26:34 -0400 (AST)
>Received: from sss2.sss.pgh.pa.us (tgl(at)localhost [127.0.0.1])by
>sss.pgh.pa.us (8.12.10/8.12.10) with ESMTP id i08LQW19016036;Thu, 8 Jan
>2004 16:26:33 -0500 (EST)
>X-Message-Info: 820stLNiepTzJGdgouOWLmzTpS/lU6jjUO41cNhiU8g=
>X-Original-To: pgsql-general-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
>In-reply-to: <200401081306(dot)23269(dot)scrawford(at)pinpointresearch(dot)com>
>References: <BAY99-F32kpDasYutu4000304b7(at)hotmail(dot)com>
><11871(dot)1073581548(at)sss(dot)pgh(dot)pa(dot)us> <3FFD8FED(dot)3000900(at)mascari(dot)com>
><200401081306(dot)23269(dot)scrawford(at)pinpointresearch(dot)com>
>Comments: In-reply-to Steve Crawford
><scrawford(at)pinpointresearch(dot)com>message dated "Thu, 08 Jan 2004 13:06:23
>-0800"
>Message-ID: <16035(dot)1073597192(at)sss(dot)pgh(dot)pa(dot)us>
>X-Virus-Scanned: by amavisd-new at postgresql.org
>X-Mailing-List: pgsql-general
>Precedence: bulk
>Return-Path: pgsql-general-owner+M55362(at)postgresql(dot)org
>X-OriginalArrivalTime: 08 Jan 2004 21:30:36.0245 (UTC)
>FILETIME=[A76F8850:01C3D62E]
>
>Steve Crawford <scrawford(at)pinpointresearch(dot)com> writes:
> > On Thursday 08 January 2004 9:14 am, Mike Mascari wrote:
> >> Is there any possibility that he's got an open transacation sitting
> >> out there for days holding a lock on that table?
>
> > Yesterday I had someone drop a table while a pg_dumpall was running.
> > The drop didn't complete till the dump was done.
>
>Yup, because pg_dump takes an AccessShareLock (reader's lock) on every
>table it intends to dump. But the process wanting to drop the table
>would have been blocked on the lock, and would not have been chewing any
>CPU time while it waited. Eric seems to be seeing something different.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings

_________________________________________________________________
Check your PC for viruses with the FREE McAfee online computer scan.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963