Re: Exhaustive list of what takes what locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Nikolas Everett <nik9000(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Exhaustive list of what takes what locks
Date: 2011-02-23 17:31:19
Message-ID: 2316.1298482279@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

(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.)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2011-02-23 17:59:31 Re: Exhaustive list of what takes what locks
Previous Message Robert Haas 2011-02-23 17:21:12 Re: Exhaustive list of what takes what locks