Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@2ndquadrant.com>

From: Andres Freund <andres@2ndquadrant.com>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Michael Paquier <michael.paquier@gmail.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:19:13Z
Lists: pgsql-hackers
On 2013-06-17 09:12:12 -0400, Peter Eisentraut wrote:
> 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.

Well, it still does the main body of work in a concurrent fashion, so I
still don't see how that argument holds that much water. But anyway, the
argument was only whether we could continue reviewing before the mvcc
stuff goes in, not whether it can get committed before.

Greetings,

Andres Freund

-- 
 Andres Freund	                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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.