| 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: 7.3.3 drop table takes very long time |
| Date: | 2004-01-08 21:26:32 |
| Message-ID: | 16035.1073597192@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Houssay | 2004-01-08 21:42:40 | vacuum |
| Previous Message | Christopher Browne | 2004-01-08 21:11:59 | Re: 7.4, 'group by' default ordering? |