Re: Should I implement DROP INDEX CONCURRENTLY? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should I implement DROP INDEX CONCURRENTLY?
Date
Msg-id CA+TgmobFn9VvAoOr4ucJvCUJfyWzjpi-n=9mi0JiszS2HDRYJw@mail.gmail.com
Whole thread Raw
In response to Re: Should I implement DROP INDEX CONCURRENTLY?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Feb 3, 2012 at 10:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> On sön, 2012-01-29 at 22:01 +0000, Simon Riggs wrote:
>>>> Patch now locks index in AccessExclusiveLock in final stage of drop.
>>>
>>> Doesn't that defeat the point of doing the CONCURRENTLY business in the
>>> first place?
>>
>> That was my initial reaction.
>>
>> We lock the index in AccessExclusiveLock only once we are certain
>> nobody else is looking at it any more.
>>
>> So its a Kansas City Shuffle, with safe locking in case of people
>> doing strange low level things.
>
> Yeah, I think this is much safer, and in this version that doesn't
> seem to harm concurrency.
>
> Given our previous experiences in this area, I wouldn't like to bet my
> life savings on this having no remaining bugs - but if it does, I
> can't find them.
>
> I'll mark this "Ready for Committer".

I don't think this has been committed - does that mean you've decided
against doing so, or just haven't had the round tuits?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: archive_keepalive_command
Next
From: Robert Haas
Date:
Subject: Re: PL/pgSQL return value in after triggers