Re: Should I implement DROP INDEX CONCURRENTLY?

On Thu, Jan 26, 2012 at 2:25 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Jan 21, 2012 at 10:11 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Your caution is wise. All users of an index have already checked
>> whether the index is usable at plan time, so although there is much
>> code that assumes they can look at the index itself, that is not
>> executed until after the correct checks.
>>
>> I'll look at VACUUM and other utilities, so thanks for that.
>>
>> I don't see much point in having the higher level lock, except perhaps
>> as a test this code works.
>
> I thought of another way this can cause a problem: suppose that while
> we're dropping the relation with only ShareUpdateExclusiveLock, we get
> as far as calling DropRelFileNodeBuffers.  Just after we finish, some
> other process that holds AccessShareLock or RowShareLock or
> RowExclusiveLock reads and perhaps even dirties a page in the
> relation.

I can't see any way that situation can occur. The patch *explicitly*
waits until all people that can see the index as usable have dropped
their lock. So I don't think this is necessary. Having said that,
since we are talking about the index and not the whole table, if I
believe the above statement then I can't have any reasonable objection
to doing as you suggest.

Patch now locks index in AccessExclusiveLock in final stage of drop.

v3 attached.

If you have suggestions to improve grammar issues, they;re most
welcome. Otherwise this seems good to go.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services