Re: REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: REINDEX CONCURRENTLY 2.0
Дата
Msg-id 61E955E2-61D7-45E8-BC66-F021EA0CE3CE@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY 2.0  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: REINDEX CONCURRENTLY 2.0  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: REINDEX CONCURRENTLY 2.0  (Oskari Saarenmaa <os@ohmu.fi>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_basebackup vs. Windows and tablespaces
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: group locking: incomplete patch, just for discussion