Re: Support for REINDEX CONCURRENTLY

Michael Paquier <michael.paquier@gmail.com>

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-09T04:31:28Z

Lists: pgsql-hackers

Attachments

20130309_1_remove_reltoastidxid_v4.patch (application/octet-stream) patch v4
20130309_2_reindex_concurrently_v22.patch (application/octet-stream) patch v22

On Sat, Mar 9, 2013 at 1:37 AM, Fujii Masao <masao.fujii@gmail.com> wrote:

> +     <para>
> +      Concurrent indexes based on a <literal>PRIMARY KEY</> or an
> <literal>
> +      EXCLUSION</>  constraint need to be dropped with <literal>ALTER
> TABLE
>
> Typo: s/EXCLUSION/EXCLUDE
>
Thanks. This is corrected.


> I encountered a segmentation fault when I ran REINDEX CONCURRENTLY.
> The test case to reproduce the segmentation fault is:
>
> 1. Install btree_gist
> 2. Run btree_gist's regression test (i.e., make installcheck)
> 3. Log in contrib_regression database after the regression test
> 4. Execute REINDEX TABLE CONCURRENTLY moneytmp
>
Oops. I simply forgot to take into account the case of system attributes
when building column names in index_concurrent_create. Fixed in new version
attached.

Regards,
-- 
Michael

Commits

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

Background worker processes
- da07a1e85651 9.3.0 cited
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
- 3c84046490be 9.3.0 cited
Work around unportable behavior of malloc(0) and realloc(NULL, 0).
- 09ac603c36d1 9.3.0 cited
Properly set relpersistence for fake relcache entries.
- beb850e1d873 9.3.0 cited