Re: Exhaustive list of what takes what locks

On Wed, Feb 23, 2011 at 12:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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