Re: Support for REINDEX CONCURRENTLY

Michael Paquier <michael.paquier@gmail.com>

From: Michael Paquier <michael.paquier@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Peter Eisentraut <peter_e@gmx.net>, Fujii Masao <masao.fujii@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2013-03-04T08:21:09Z
Lists: pgsql-hackers

Attachments

Hi,

Please find attached an updated patch fixing the following issues:
- gin and gist indexes are now rebuilt correctly. Some option values were
not passed to the concurrent indexes (reported by Masao)
- swap is done with relfilenode and not names. In consequence
pg_stat_user_indexes is not reset (reported by Peter).
I am looking at the issue reported previously with make installcheck.
Regards,

On Sun, Mar 3, 2013 at 9:54 PM, Andres Freund <andres@2ndquadrant.com>wrote:

> On 2013-03-01 16:32:19 -0500, Peter Eisentraut wrote:
> > REINDEX CONCURRENTLY resets the statistics in pg_stat_user_indexes,
> > whereas plain REINDEX does not.  I think they should be preserved in
> > either case.
>
> Yes. Imo this further suggests that it would be better to switch the
> relfilenodes (+indisclustered) of the two indexes instead of switching
> the names. That would allow to get rid of the code for moving over
> dependencies as well.
> Given we use an exclusive lock for the switchover phase anyway, there's
> not much point in going for the name-based switch. Especially as some
> eventual mvcc-correct system access would be fine with the relfilenode
> method.
>
> Greetings,
>
> Andres Freund
>
> --
>  Andres Freund                     http://www.2ndQuadrant.com/
>  PostgreSQL Development, 24x7 Support, Training & Services
>



-- 
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.