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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
