Hi hackers, 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. The second run succeeds but leaves an index with an INVALID status. I think this is not the desired behaviour.
# TEST postgres=> CREATE TABLE part1(c1 INT) PARTITION BY RANGE(c1); CREATE TABLE postgres=> CREATE TABLE part1v1 PARTITION OF part1 FOR VALUES FROM (0) TO (100); CREATE TABLE postgres=> CREATE INDEX idx1_part1 ON part1(c1); CREATE INDEX postgres=> REINDEX TABLE CONCURRENTLY part1v1; ERROR: cannot drop index part1v1_c1_idx_ccold because index idx1_part1 requires it HINT: You can drop index idx1_part1 instead. postgres=> \d+ part1v1 Table "public.part1v1" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------+-----------+----------+---------+---------+--------------+------------- c1 | integer | | | | plain | | Partition of: part1 FOR VALUES FROM (0) TO (100) Partition constraint: ((c1 IS NOT NULL) AND (c1 >= 0) AND (c1 < 100)) Indexes: "part1v1_c1_idx" btree (c1) "part1v1_c1_idx_ccold" btree (c1) INVALID Access method: heap postgres=> REINDEX TABLE CONCURRENTLY part1v1; REINDEX postgres=> \d+ part1v1 Table "public.part1v1" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------+-----------+----------+---------+---------+--------------+------------- c1 | integer | | | | plain | | Partition of: part1 FOR VALUES FROM (0) TO (100) Partition constraint: ((c1 IS NOT NULL) AND (c1 >= 0) AND (c1 < 100)) Indexes: "part1v1_c1_idx" btree (c1) "part1v1_c1_idx_ccold" btree (c1) INVALID Access method: heap Regards, Noriyoshi Shinoda -----Original Message----- From: Michael Paquier [mailto:mich...@paquier.xyz] Sent: Friday, March 29, 2019 6:21 PM To: Peter Eisentraut <peter.eisentr...@2ndquadrant.com> Cc: Sergei Kornilov <s...@zsrv.org>; pgsql-hackers@lists.postgresql.org Subject: Re: REINDEX CONCURRENTLY 2.0 On Fri, Mar 29, 2019 at 09:13:35AM +0100, Peter Eisentraut wrote: > So, we're getting buildfarm failures, only with clang. I can > reproduce those (with clang). Indeed, I can reproduce the failures using -O2 with clang. I am wondering if we are not missing a volatile flag somewhere and that some code reordering is at cause here. > It seems the issue is somewhere near indexcmds.c "Phase 6 of REINDEX > CONCURRENTLY". More eyes welcome. Here is a short reproducer: create materialized view aam as select 1 AS a; create index aai on aam(a); reindex table CONCURRENTLY aam; -- Michael