Re: Support for REINDEX CONCURRENTLY

On 6/17/13 9:19 AM, Andres Freund wrote:
>> Without getting rid of the AccessExclusiveLock, REINDEX CONCURRENTLY is
>> not really concurrent, at least not concurrent to the standard set by
>> CREATE and DROP INDEX CONCURRENTLY.
> 
> Well, it still does the main body of work in a concurrent fashion, so I
> still don't see how that argument holds that much water.

The reason we added DROP INDEX CONCURRENTLY is so that you don't get
stuck in a lock situation like

long-running-transaction <- DROP INDEX <- everything else

If we accepted REINDEX CONCURRENTLY as currently proposed, then it would
have the same problem.

I don't think we should accept a REINDEX CONCURRENTLY implementation
that is worse in that respect than a manual CREATE INDEX CONCURRENTLY +
DROP INDEX CONCURRENTLY combination.