Re: list_free in addRangeTableEntryForJoin - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: list_free in addRangeTableEntryForJoin
Date
Msg-id CAEudQAp8R7aDjg09-H=Gfn1b64H9DM=C=wMpWuY=GUbDyNAkrA@mail.gmail.com
Whole thread Raw
In response to list_free in addRangeTableEntryForJoin  (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>)
List pgsql-hackers
Em seg., 10 de jun. de 2024 às 07:35, Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> escreveu:
Hi Hackers

I have identified a potential memory leak in the
`addRangeTableEntryForJoin()` function. The second parameter of
`addRangeTableEntryForJoin()`, `colnames`, is a `List*` that is
concatenated with another `List*`, `eref->colnames`, using
`list_concat()`. We need to pass only the last `numaliases` elements of
the list, for which we use `list_copy_tail`. This function creates a
copy of the `colnames` list, resulting in `colnames` pointing to the
current list that will not be freed. Consequently, a new list is already
concatenated.

To address this issue, I have invoked `list_free(colnames)` afterwards.
If anyone is aware of where the list is being freed or has any
suggestions for improvement, I would greatly appreciate your input.
list_copy_tail actually makes a new copy.
But callers of addRangeTableEntryForJoin,
expects to handle a list or NIL, if we free the memory,
Shouldn't I set the variable *colnames* to NIL, too?

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Conflict Detection and Resolution
Next
From: Tomas Vondra
Date:
Subject: Re: Conflict Detection and Resolution