Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id CAB7nPqRr397u7PhT8CmZy+CNSu=cg7X85iosmLkdEvocUz9atA@mail.gmail.com
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY 2.0  (Oskari Saarenmaa <os@ohmu.fi>)
List 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 by date:

Previous
From: Jeff Janes
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Next
From: Guillaume Lelarge
Date:
Subject: Re: Maximum number of WAL files in the pg_xlog directory