Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, Fujii Masao <masao.fujii@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-06-17T13:12:12Z
Lists: pgsql-hackers 
On 6/17/13 8:23 AM, Michael Paquier wrote:
> As mentionned by Andres, the only thing that the MVCC catalog patch can
> improve here
> is the index swap phase (index_concurrent_swap:index.c) where the
> relfilenode of the
> old and new indexes are exchanged. Now an AccessExclusiveLock is taken
> on the 2 relations
> being swap, we could leverage that to ShareUpdateExclusiveLock with the
> MVCC catalog
> access I think.

Without getting rid of the AccessExclusiveLock, REINDEX CONCURRENTLY is
not really concurrent, at least not concurrent to the standard set by
CREATE and DROP INDEX CONCURRENTLY.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.