Re: Fix a resource leak (src/backend/utils/adt/rowtypes.c) - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Fix a resource leak (src/backend/utils/adt/rowtypes.c)
Date
Msg-id CAEudQArvbWEr4cbbxqEVOJsSBaUwV0J5FaMcSxgXyr46qJEsyQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix a resource leak (src/backend/utils/adt/rowtypes.c)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Em seg., 14 de abr. de 2025 às 16:59, Robert Haas <robertmhaas@gmail.com> escreveu:
On Sun, Apr 13, 2025 at 7:34 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
> CID 1608916: (#1 of 1): Resource leak (RESOURCE_LEAK)
> 52. leaked_storage: Variable buf going out of scope leaks the storage buf.data points to.
>
> The function *record_in* has a new report about resource leak.
> I think Coverity is right.

I agree, for small values of "right".
Thanks.
 
The memory isn't formally leaked
because it will be eventually released when the containing memory
context is deleted, but it's unclear why we should bother to clean up
the memory in the normal path yet skip it here. I wondered whether the
existing pfree calls were added in response to some specific
complaint, but it doesn't appear so: they date back to Tom's 2004-era
commit a3704d3deca6d08013a6b1db0432b75dc6b78d28,
Thanks for researching.
 
the commit message
for which is rather more brief than what is typical today. Still, it
seems safer to bet on the pfree being a good idea than on the reverse,
because record_in() can be called lots of times in a single
transaction.
I think that material for v18, although there were no reported concerns.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [18] Unintentional behavior change in commit e9931bfb75
Next
From: Noah Misch
Date:
Subject: Re: Call for Posters: PGConf.dev 2025