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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)
Date: 2025-02-05 18:56:26
Message-ID: 918121.1738781786@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 5 Feb 2025, at 18:34, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>> This is evidence that we do not have reports about this bug.

> Before that can be stated it needs to be determined if this is a bug, this
> thread has not done that yet.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-02-05 18:59:22 Re: Fix assert failure when decoding XLOG_PARAMETER_CHANGE on primary
Previous Message Álvaro Herrera 2025-02-05 18:51:20 Re: log_min_messages per backend type