Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Date
Msg-id 20190723042838.GB2059@paquier.xyz
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Mon, Jul 22, 2019 at 05:41:26PM -0400, Tom Lane wrote:
> I think the correct fix is to nuke the code in REINDEX CONCURRENTLY that
> thinks it should use any of this infrastructure to fetch the existing
> index properties, and just have it read the catalog directly instead.

Okay.  Sharing a maximum the build of IndexInfo done as part of
DefineIndex is something that we should do then.  Attached is a patch
that I have been working on, introducing a new makeIndexInfo() in
makefuncs.c. Still as IndexInfo is not a parse node but an exec node,
I am including execnodes.h in makefuncs.h for now (perhaps somebody
has a better idea?).  This fills the index information of the new
entry directly from the catalog of the old entry for expressions and
predicates.

I have let BuildIndexInfo out of that as ii_ReadyForInserts can change
for system catalogs during bootstrap.  I have also reworked the test
case to just use pg_get_indexdef() which is enough to show the
original bug as after the initial REINDEX CONCURRENTLY the collation
part goes missing when testing on HEAD.  Predicates need to properly
be formatted with an implicit-AND format by the way.

Thoughts?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Next
From: 高 云龙
Date:
Subject: A function privilege problem