| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Oskari Saarenmaa <os(at)ohmu(dot)fi> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(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-12-30 08:12:59 |
| Message-ID: | CAB7nPqRr397u7PhT8CmZy+CNSu=cg7X85iosmLkdEvocUz9atA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 23, 2014 at 5:54 PM, Oskari Saarenmaa <os(at)ohmu(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Lelarge | 2014-12-30 08:35:24 | Re: Maximum number of WAL files in the pg_xlog directory |
| Previous Message | Jeff Janes | 2014-12-30 07:52:49 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |