On Wed, Feb 23, 2011 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> ...but that begs the question of why DROP INDEX needs an
>> AccessExclusiveLock. It probably needs such a lock *on the index* but
>> I don't see why we'd need it on the table.
>
> Some other session might be in process of planning a query on the table.
> It would be sad if the index it had chosen turned out to have vanished
> meanwhile. You could perhaps confine DROP INDEX's ex-lock to the index,
> but only at the price of making the planner take out a lock on every
> index it considers even transiently. Which isn't going to be a net
> improvement.
Oh. I assumed we were doing that anyway. If not, yeah.
> (While we're on the subject, I have strong suspicions that most of what
> Simon did this cycle on ALTER TABLE lock strength reduction is
> hopelessly broken and will have to be reverted. It's on my to-do list
> to try to break that patch during beta, and I expect to succeed.)
It wouldn't surprise me if there are some holes there. But I'd like
to try to preserve as much of it as we can, and I think there's
probably a good chunk of it that is OK.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
