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 08:08:28 |
Message-ID: | CAMbWs49P6+7dekSSe5z4thr3AMvuYAJy5GKD5HKzw8x+8oR9hw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Sep 3, 2025 at 10:19 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > 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?
> Yeah, "is there any other instance of this problem?" is the $64
> question here. I was initially thinking v17 is sufficient, but
> the possibility that some extension might be vulnerable makes
> me lean to back-patching further. Your call ...
I've decided to backpatch this fix to pre-v17 branches: using a root
that lacks a valid simple_rel_array in a cost estimation function
seems like a pitfall waiting to happen. I've included an explanation
of this backpatch decision in the commit message and have pushed the
fix (the test case is not included in pre-v17 branches though).
- Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-09-03 08:56:39 | Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error |
Previous Message | Michael Paquier | 2025-09-03 03:58:45 | Re: Broken PQtrace CopyData display |