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 20190725103113.GB10546@paquier.xyz
Whole thread Raw
In response to Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
Responses Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
List pgsql-bugs
On Tue, Jul 23, 2019 at 01:28:38PM +0900, Michael Paquier wrote:
> 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 been looking at this code today and extended the test cases
with more expression and predicate indexes to stress more the patch,
and it happens that I am still stuck for with makeIndexInfo().  The
header comments of makefuncs.h and makefuncs.c mention primitive
nodes, so I would need at least to update that part to mention
execution nodes.  Still I'd rather not have people scream at me as
that could be considered invasive in terms of included dependencies
for makefuncs.c :)

If we don't have the makeIndexInfo wrapper, please note that we finish
by filling in three times IndexInfo with roughly the same data in
different places, so I would like to keep it.

So, are there any opinions or ideas about that?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Daniel Migowski
Date:
Subject: AW: BUG #15923: Prepared statements take way too much memory.
Next
From: Andrey Borodin
Date:
Subject: Re: Logging corruption error codes