On 2013-06-17 11:03:35 -0400, Peter Eisentraut wrote: > 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.
Well, it can do lots stuff that DROP/CREATE CONCURRENTLY can't: * reindex primary keys * reindex keys referenced by foreign keys * reindex exclusion constraints * reindex toast tables * do all that for a whole database so I don't think that comparison is fair. Having it would have made several previous point releases far less painful (e.g. 9.1.6/9.2.1). But anyway, the as I said "the argument was only whether we could continue reviewing before the mvcc stuff goes in, not whether it can get committed before.". I don't think we a have need to decide whether REINDEX CONCURRENTLY can go in with the short exclusive lock unless we find unresolveable problems with the mvcc patch. Which I very, very much hope not to be the case. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
