Horton

Re: REINDEX CONCURRENTLY 2.0

Michael Paquier <michael.paquier@gmail.com>

View thread View on postgr.es
From: Michael Paquier <michael.paquier@gmail.com>
To: Oskari Saarenmaa <os@ohmu.fi>
Cc: Andres Freund <andres@2ndquadrant.com>, Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>, Jim Nasby <jim@nasby.net>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2014-12-30T08:12:59Z
Lists: 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

Commits

  1. Prevent reindex of invalid indexes on TOAST tables

  2. Rework handling of invalid indexes with REINDEX CONCURRENTLY

  3. Split builtins.h to a new header ruleutils.h