Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
Date: 2025-09-03 00:42:34
Message-ID: CAMbWs4-g7LJ+W_dL1_=O6OOZ=wwxtUPbwypdgsVWMnm=wcW1Yw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Sep 3, 2025 at 12:27 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > Here is the patch that passes root as NULL to cost_qual_eval() in
> > cost_subplan(), along with some commentary about why.

> v2 LGTM. I did think of a way to make the test case a little
> less busy-looking:
>
> select (1 = any(array_agg(f1))) = any (select false) from int4_tbl;
>
> but that's just cosmetic.

Thanks, I'll take this test case.

One thing I'm not quite sure about is whether we should backpatch this
fix to pre-v17 branches. Prior to v17, estimate_array_length() wasn't
taught to use statistics, so this error isn't reproducible there.
OTOH, passing a root without a valid simple_rel_array to
cost_qual_eval() still seems potentially unsafe. What do you think?

- Richard

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-09-03 01:19:15 Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
Previous Message 李海洋 (陌痕) 2025-09-03 00:06:31 回复:BUG #19040: Memory leak in hashed subplan node due to missing hashtempcxt reset