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