Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 61E955E2-61D7-45E8-BC66-F021EA0CE3CE@2ndquadrant.com
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: REINDEX CONCURRENTLY 2.0  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: REINDEX CONCURRENTLY 2.0  (Oskari Saarenmaa <os@ohmu.fi>)
List pgsql-hackers
On November 13, 2014 10:23:41 PM CET, Peter Eisentraut <peter_e@gmx.net> wrote:
>On 11/12/14 7:31 PM, Andres Freund wrote:
>> Yes, it sucks. But it beats not being able to reindex a relation with
>a
>> primary key (referenced by a fkey) without waiting several hours by a
>> couple magnitudes. And that's the current situation.
>
>That's fine, but we have, for better or worse, defined CONCURRENTLY :=
>does not take exclusive locks.  Use a different adverb for an
>in-between
>facility.

I think that's not actually a service to our users. They'll have to adapt their scripts and knowledge when we get
aroundto the more concurrent version. What exactly CONCURRENTLY means is already not strictly defined and differs
betweenthe actions.
 

I'll note that DROP INDEX CONCURRENTLY actually already  internally acquires an AEL lock. Although it's a bit harder to
seethe consequences of that.
 

-- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

Andres Freund                       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_basebackup vs. Windows and tablespaces
Next
From: Jeff Davis
Date:
Subject: Re: group locking: incomplete patch, just for discussion