Re: REINDEX CONCURRENTLY 2.0

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: "Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi(dot)shinoda(at)hpe(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-01 06:43:43
Message-ID: 20190401064343.GA16093@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Sat, Mar 30, 2019 at 11:56:27AM +0100, Peter Eisentraut wrote:
> The attached patch fixes this. The issue was that we didn't move all
> dependencies from the index (only in the other direction). Maybe that
> was sufficient when the patch was originally written, before partitioned
> indexes.

Hm. I don't think that it is quite right either because the new index
is missing from the partition tree after the reindex. Taking the
example from your patch I see that:
=# CREATE TABLE concur_reindex_part1 (c1 int) PARTITION BY RANGE (c1);
CREATE TABLE
=# CREATE TABLE concur_reindex_part1v1 PARTITION OF
concur_reindex_part1 FOR VALUES FROM (0) TO (100);
CREATE TABLE
=# SELECT relid, level FROM
pg_partition_tree('concur_reindex_idx1_part1');
relid | level
-------------------------------+-------
concur_reindex_idx1_part1 | 0
concur_reindex_part1v1_c1_idx | 1
(2 rows)
=# CREATE INDEX concur_reindex_idx1_part1 ON
concur_reindex_part1 (c1);
CREATE INDEX
=# REINDEX TABLE CONCURRENTLY concur_reindex_part1v1;
REINDEX
SELECT relid, level FROM
pg_partition_tree('concur_reindex_idx1_part1');
relid | level
---------------------------+-------
concur_reindex_idx1_part1 | 0
(1 row)

And I would have expected concur_reindex_part1v1_c1_idx to still be
part of the partition tree. I think that the issue is in
index_concurrently_create_copy() where we create the new index with
index_create() without setting parentIndexRelid, causing the
dependency to be lost. This parameter ought to be set to the OID of
the parent index so I think that we need to look at the ancestors of
the index if relispartition is set, and use get_partition_ancestors()
for that purpose.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2019-04-01 06:57:41 Re: Re: FETCH FIRST clause WITH TIES option
Previous Message Michael Paquier 2019-04-01 06:39:45 Re: REINDEX CONCURRENTLY 2.0