Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Date: 2019-07-25 10:31:13
Message-ID: 20190725103113.GB10546@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrey Borodin 2019-07-25 10:45:00 Re: Logging corruption error codes
Previous Message Alban Hertroys 2019-07-25 08:39:15 Re: Request for resolution || Support