| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | "Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi(dot)shinoda(at)hpe(dot)com> |
| Cc: | 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-03-30 01:19:17 |
| Message-ID: | 20190330011917.GM1954@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 29, 2019 at 03:10:23PM +0000, Shinoda, Noriyoshi (PN Japan A&PS Delivery) wrote:
> I tried this great feature for partition index.
> The first time the REINDEX TABLE CONCURRENTLY statement is executed
> to the partition, then an error occurs.
Yes, that's a problem. I am adding an open item.
> The second run succeeds but leaves an index with an INVALID status.
> I think this is not the desired behaviour.
This one is partially expected actually. Invalid indexes are ignored
when processing as that would cause at least a table-level reindex to
double its amount of processing. However, it is not possible either
to detach an index from an partition tree for indexes, hence the index
cannot be dropped directly either. It seems to me that the root of
the problem is that the partition indexes created as copycats of the
original ones should never be in a state where they are attached to
the index tree.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-03-30 01:44:09 | Re: REINDEX CONCURRENTLY 2.0 |
| Previous Message | Michael Paquier | 2019-03-30 01:08:22 | Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru |