On Wed, Feb 23, 2011 at 12:31 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
