Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)
| От | Tom Lane |
|---|---|
| Тема | Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c) |
| Дата | |
| Msg-id | 918121.1738781786@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c) (Daniel Gustafsson <daniel@yesql.se>) |
| Ответы |
Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c)
Re: Avoid possible deference NULL pointer (src/backend/optimizer/path/allpaths.c) |
| Список | pgsql-hackers |
Daniel Gustafsson <daniel@yesql.se> writes:
> On 5 Feb 2025, at 18:34, Ranier Vilela <ranier.vf@gmail.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
В списке pgsql-hackers по дате отправления: