Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)

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.

In response to

Browse pgsql-hackers by date

  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 ?