Re: REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX CONCURRENTLY 2.0
Дата
Msg-id CAB7nPqRr397u7PhT8CmZy+CNSu=cg7X85iosmLkdEvocUz9atA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY 2.0  (Oskari Saarenmaa <os@ohmu.fi>)
Список pgsql-hackers
On Tue, Dec 23, 2014 at 5:54 PM, Oskari Saarenmaa <os@ohmu.fi> wrote:
>
> If the short-lived lock is the only blocker for this feature at the
> moment could we just require an additional qualifier for CONCURRENTLY
> (FORCE?) until the lock can be removed, something like:
> =# [blah]

FWIW, I'd just keep only CONCURRENTLY with no fancy additional
keywords even if we cheat on it, as long as it is precised in the
documentation that an exclusive lock is taken for a very short time,
largely shorter than what a normal REINDEX would do btw.

> It's not optimal, but currently there's no way to reindex a primary key
> anywhere close to concurrently and a short lock would be a huge
> improvement over the current situation.
Yep.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Следующее
От: Guillaume Lelarge
Дата:
Сообщение: Re: Maximum number of WAL files in the pg_xlog directory