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

Re: Should I implement DROP INDEX CONCURRENTLY?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Daniel Farina <daniel(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should I implement DROP INDEX CONCURRENTLY?
Date: 2012-03-28 13:51:54
Message-ID: CA+TgmobFn9VvAoOr4ucJvCUJfyWzjpi-n=9mi0JiszS2HDRYJw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb 3, 2012 at 10:28 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-03-28 13:57:10
Subject: Re: PL/pgSQL return value in after triggers
Previous:From: Robert HaasDate: 2012-03-28 13:49:40
Subject: Re: archive_keepalive_command

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