Re: REINDEX CONCURRENTLY 2.0 - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: REINDEX CONCURRENTLY 2.0
Date
Msg-id 154954968565.11785.6973123402105637191.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: REINDEX CONCURRENTLY 2.0  (Sergei Kornilov <sk@zsrv.org>)
List pgsql-hackers
The following review has been posted through the commitfest application:
make installcheck-world:  tested, passed
Implements feature:       tested, passed
Spec compliant:           not tested
Documentation:            tested, passed

Hello
Sorry for late response. I review latest patch version.

I didn't found any new behavior bugs.

reindex concurrenlty can be in deadlock with another reindex concurrently (or manual vacuum (maybe with wraparound
autovacuum)or create index concurrently on same table). But i think this is not issue for this feature, two create
indexconcurrently can be in deadlock too.
 

Just one small note for documentation:

> +Indexes:
> +    "idx" btree (col)
> +    "idx_cct" btree (col) INVALID

Second index should be idx_ccnew (or idx_ccold), right?

Code looks good for me.

regards, Sergei

pgsql-hackers by date:

Previous
From: "REIX, Tony"
Date:
Subject: RE: Shared Memory: How to use SYSV rather than MMAP ?
Next
From: Daniel Gustafsson
Date:
Subject: Re: Tighten up a few overly lax regexes in pg_dump's tap tests