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
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 |