Re: REINDEX CONCURRENTLY 2.0

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>,Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REINDEX CONCURRENTLY 2.0
Date: 2014-11-13 21:50:21
Message-ID: 61E955E2-61D7-45E8-BC66-F021EA0CE3CE@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On November 13, 2014 10:23:41 PM CET, Peter Eisentraut <peter_e(at)gmx(dot)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 around to the more concurrent version. What exactly CONCURRENTLY means is already not strictly defined and differs between the actions.

I'll note that DROP INDEX CONCURRENTLY actually already internally acquires an AEL lock. Although it's a bit harder to see the 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2014-11-13 21:57:01 Re: group locking: incomplete patch, just for discussion
Previous Message Robert Haas 2014-11-13 21:49:56 Re: pg_basebackup vs. Windows and tablespaces