Re: Slow DROP INDEX

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "'Rod Taylor'" <pg(at)rbt(dot)ca>
Cc: "'PostgreSQL Development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Slow DROP INDEX
Date: 2004-02-16 23:07:24
Message-ID: 000401c3f4e1$a6701c90$c19d87d9@LaptopDellXP
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Rod Taylor
> On Mon, 2004-02-16 at 13:03, Tom Lane wrote:
> > Rod Taylor <pg(at)rbt(dot)ca> writes:
> > > The real question is why does DROP INDEX take more than a couple
of
> > > seconds to complete? It is not held up by locked.
> >
> > AFAICS it shouldn't take any time to complete. I think you're
mistaken
> > and it is blocking on a lock (it will want exclusive lock on the
table).
> > Everyone else will then queue up behind it.
>
> I not convinced it is waiting on a lock. The queries on that table are
> very short (couple of milliseconds) -- but there are a ton of them.
All
> backends appear to be idle (pg_stat_activity with command shown) when
we
> start the drop and shortly after huge backups occur.

Could it be waiting on a lock held on something other than the target
table itself?

A system catalog table, either for access right or optimization? Maybe
the drop index lock is the same as the drop table lock (and perhaps it
shouldn't be).

May not be the case...but the answer should be interesting.

Hope it helps, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2004-02-16 23:07:25 Re: Proposals for PITR
Previous Message Devrim GUNDUZ 2004-02-16 21:37:56 Re: Replication eRServer problems