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.