pgsql: Fix list_copy_head() with empty Lists
Fix list_copy_head() with empty Lists
list_copy_head() given an empty List would crash from trying to
dereference the List to obtain its length. Since NIL is how we represent
an empty List, we should just be returning another empty List in this
case.
list_copy_head() is new to v16, so let's fix it now before too many people
start coding around the buggy NIL behavior.
Reported-by: Miroslav Bendik
Discussion: /messages/by-id/CAPoEpV02WhawuWnmnKet6BqU63bEu7oec0pJc=nKMtPsHMzTXQ@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e35ded29566f679e52888a8d34468bb51bc78bed
Modified Files
--------------
src/backend/nodes/list.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
David Rowley <drowley@postgresql.org> writes:
Fix list_copy_head() with empty Lists
list_copy_head() given an empty List would crash from trying to
dereference the List to obtain its length. Since NIL is how we represent
an empty List, we should just be returning another empty List in this
case.
I see that list_copy_head exists in v15 as well. It appears to have
no callers there, but we'd better fix it anyway in case somebody
back-patches a fix that uses it.
Or, maybe, remove it in 15?
regards, tom lane
On Fri, 21 Apr 2023 at 01:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I see that list_copy_head exists in v15 as well. It appears to have
no callers there, but we'd better fix it anyway in case somebody
back-patches a fix that uses it.
Doh :-( Thanks for alerting me. I've just applied the patch to REL_15_STABLE.
I kept the same commit message as master, which I think was the
correct thing to do, despite it containing information that wasn't
true. I know the script used to assist release note creation goes on
commit messages to determine which commits went into which branches.
Or, maybe, remove it in 15?
I chickened out of that as it does not seem impossible that someone is
making use of it. It seems lightweight enough not to have to worry
too much about keeping it around.
David
David Rowley <dgrowleyml@gmail.com> writes:
Doh :-( Thanks for alerting me. I've just applied the patch to REL_15_STABLE.
I kept the same commit message as master, which I think was the
correct thing to do, despite it containing information that wasn't
true. I know the script used to assist release note creation goes on
commit messages to determine which commits went into which branches.
Yeah, that's definitely easier for release notes, so thanks.
regards, tom lane