Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Peter Eisentraut <peter_e@gmx.net>

View thread
From: Peter Eisentraut <peter_e@gmx.net>
To: Andres Freund <andres@2ndquadrant.com>
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-17T15:03:35Z
Lists: pgsql-hackers 
On 6/17/13 9:19 AM, Andres Freund wrote:
>> 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.

The reason we added DROP INDEX CONCURRENTLY is so that you don't get
stuck in a lock situation like

long-running-transaction <- DROP INDEX <- everything else

If we accepted REINDEX CONCURRENTLY as currently proposed, then it would
have the same problem.

I don't think we should accept a REINDEX CONCURRENTLY implementation
that is worse in that respect than a manual CREATE INDEX CONCURRENTLY +
DROP INDEX CONCURRENTLY combination.

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.