[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Exhaustive list of what takes what locks
From:       Robert Haas <robertmhaas () gmail ! com>
Date:       2011-02-23 17:59:31
Message-ID: AANLkTin2QKROAP51xsf46Wc5xdev346UUmd_tpNmmY9P () mail ! gmail ! com
[Download RAW message or body]

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

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[prev in list] [next in list] [prev in thread] [next in thread]