Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group