| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: REINDEX CONCURRENTLY 2.0 |
| Date: | 2019-04-12 03:10:46 |
| Message-ID: | 20190412031046.GD2144@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Apr 11, 2019 at 09:49:47AM -0400, Alvaro Herrera wrote:
> Hmm, I suppose that makes sense for REINDEX TABLE or anything that
> reindexes more than one index, but if you do REINDEX INDEX surely it
> is reasonable to allow the case?
Yes, we could revisit the REINDEX INDEX portion of the decision, and
after sleeping on it my previous argument makes limited sense for
REINDEX processes using only one index. One could note that the
header comment of ReindexRelationConcurrently() kind of implies the
same conclusion as you do, but that's perhaps just an accident.
So... I am coming up with the patch attached. I have introduced some
tests using a trick with CIC to have an invalid index to work on.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| reindex-conc-invalid.patch | text/x-diff | 6.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2019-04-12 03:27:11 | Re: Attempt to consolidate reading of XLOG page |
| Previous Message | Jamison, Kirk | 2019-04-12 02:41:37 | Minor fix in reloptions.c comments |