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

From Tom Lane
Subject Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Date
Msg-id 20401.1563831686@sss.pgh.pa.us
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
Michael Paquier <michael@paquier.xyz> writes:
> I have done some work on that, and for now I am finishing with the
> attached.  This takes the approach of updating BuildIndexInfo() so as
> the optimizations for the planner are not done.

This seems like a really bad idea.

As you have it, whether the relcache contains optimized or unoptimized
expressions will be basically chance, depending on which sort of call
happened first after the last cache flush.  That will break things,
because for most use-cases it's *not* optional to apply
eval_const_expressions.

Even without that, changing the APIs of the functions you've touched
here seems pretty invasive.

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.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Logging corruption error codes
Next
From: Michael Paquier
Date:
Subject: Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail