From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Subject: | Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c) |
Date: | 2025-02-05 21:53:12 |
Message-ID: | de25a69a-8604-454d-8011-4a9f574a2d69@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05.02.2025 21:56, Tom Lane wrote:
> It's not a bug. Since the call specifies NIL pathkeys (meaning it
> doesn't care about sort order) and does not insist on a parallel-safe
> path, there should always be a path that satisfies it. The only
> way it could fail to find a path is if the rel's pathlist is entirely
> empty, a case already rejected by the sole caller.
>
> Moreover, the argument that we might not have gotten a report is not
> credible. In a production build without an Assert, the next line
> would still dump core just as effectively if the result were NULL.
>
> While the proposed patch doesn't break anything, it's removing a
> logic cross-check that was put there intentionally. So I don't
> find it to be an improvement.
>
> regards, tom lane
Ah, if this Assert was intentionally added to ensure that a path must be
always found under the given conditions, and that any issues with this
can be detected in the right place, then I agree. The patch likely makes
worse.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2025-02-05 22:08:09 | Re: Trigger more frequent autovacuums of heavy insert tables |
Previous Message | Nathan Bossart | 2025-02-05 21:52:31 | Re: New GUC autovacuum_max_threshold ? |