Re: BUG #17997: Assert failed in validatePartitionedIndex() when attaching partition index to child of valid index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17997: Assert failed in validatePartitionedIndex() when attaching partition index to child of valid index
Date: 2023-08-02 18:01:40
Message-ID: 3303210.1690999300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Fri, Jun 30, 2023 at 07:00:00AM +0300, Alexander Lakhin wrote:
>> Yeah, in regard to that, your patch looks good to me.
>> Thank you!

> Cool, I have fixed this issue, then. The buildfarm looks OK with it.

While going through the commit log to prepare release notes, I was
struck by the fact that this commit (fc55c7ff8 et al) takes the
approach of ignoring invalid child indexes during ATTACH PARTITION:

I have studied a few options here (like the possibility to switch
indisvalid to false for the parent), but came down to the conclusion
that we'd better rely on a simple rule: invalid indexes had better never
be chosen, so as the partition attached uses and creates indexes that
the parent expects.

However, your later fix for handling invalid child indexes during
CREATE PARTITIONED INDEX (cfc43aeb3 et al) does the opposite:

This patch makes sure that indisvalid is set to false on a partitioned
index if at least one of its partition is invalid. The flag is set to
true if *all* its partitions are valid.

This seems inconsistent: why do we behave one way during CREATE and
another during ATTACH? Do we even need fc55c7ff8's logic change
anymore? That is, is it possible that the fixes added by cfc43aeb3
would be enough to resolve the problem (though with a different
outcome that the partitioned index remains invalid after ATTACH
PARTITION)?

Perhaps the week before minor releases is not the time to be fooling
around with this, but it seems like an odd set of choices.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-08-02 18:35:46 Re: [BUG REPORT] Unexpected cast while matching CHAR type
Previous Message 翁思扬 2023-08-02 17:23:16 [BUG REPORT] Unexpected cast while matching CHAR type