Re: assertion failure with unique index + partitioning + join - Mailing list pgsql-hackers

From Richard Guo
Subject Re: assertion failure with unique index + partitioning + join
Date
Msg-id CAMbWs491iHkC=xNE5VjHYNw3JH4f1wXW1QBoFBNwHdb9DpNPLw@mail.gmail.com
Whole thread
In response to Re: assertion failure with unique index + partitioning + join  (Tender Wang <tndrwang@gmail.com>)
Responses Re: assertion failure with unique index + partitioning + join
List pgsql-hackers
On Thu, Jun 18, 2026 at 10:01 PM Tender Wang <tndrwang@gmail.com> wrote:
> In remove_rel_from_phvs_mutator(), we have:
>
> else if (IsA(node, Query))
>     {
>         Query      *newnode;
>
>        ...
>    }
>
> I want to find what kind of SQL can enter the above else-if block.
> So I added "assert(0)" to the else-if block. But no regression test crashed.
> We test rel->baserestrictinfo here. Is it possible that the clause
> includes a Query structure?

Good point.  I considered this, and the answer is no.  Any SubLink
that could contain a Query has already been expanded into a SubPlan by
the time we reach left-join removal, so we never encounter a Query
here.

I think what I had in mind when I wrote that branch was a SubLink
wrapped in a PHV with phlevelsup > 0, since SS_process_sublinks does
not recurse into the arguments of such an outer-level PHV.  But that
case cannot arise here either: at left-join removal we only ever see
phlevelsup == 0 PHVs, because upper-level ones have already been
replaced with Params.

So we can drop the 'else if' branch.  And we can remove sublevels_up
from remove_rel_from_phvs_context, and that makes it a one-field
struct, so we can remove the struct as well and just pass the Relids
directly.

Patch updated.

- Richard

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Performance Degradation (Table becomes bloat) During Repeated Bulk UPDATE Operations
Next
From: David Rowley
Date:
Subject: Re: Fix tuple deformation with virtual generated NOT NULL columns