Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Michael Paquier <michael.paquier@gmail.com>

View thread
From: Michael Paquier <michael.paquier@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-03-16T18:31:44Z
Lists: pgsql-hackers 
On 2013/03/17, at 0:35, Fujii Masao <masao.fujii@gmail.com> wrote:

> On Wed, Mar 13, 2013 at 9:04 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> I have been working on improving the code of the 2 patches:
> 
> I found pg_dump dumps even the invalid index. But pg_dump should
> ignore the invalid index?
> This problem exists even without REINDEX CONCURRENTLY patch. So we might need to
> implement the bugfix patch separately rather than including the bugfix
> code in your patches.
> Probably the backport would be required. Thought?
Hum... Indeed, they shouldn't be included... Perhaps this is already known?
> 
> We should add the concurrent reindex option into reindexdb command?
> This can be really
> separate patch, though.
Yes, they definitely should be separated for simplicity.
Btw, those patches seem trivial, I'll send them.

Michael

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.