Re: Avoid resource leak (src/test/modules/test_binaryheap/test_binaryheap.c)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Avoid resource leak (src/test/modules/test_binaryheap/test_binaryheap.c)
Date: 2025-09-12 22:53:10
Message-ID: 2664473.1757717590@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Sep 12, 2025 at 1:54 PM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> wrote:
>> Coverity reports this resource leak in test_binaryheap module.
>> I think that is right.

> If this were correct, we'd need to also free the memory in all the
> error paths. But of course, in both error and non-error paths, we rely
> on memory context cleanup to free memory for us, except in cases where
> there's some specific reason to believe that's not good enough. I
> doubt that there is any such reason in this case.

I agree this isn't interesting from a resource-leak perspective.
However, is it interesting from a test-coverage perspective?
AFAICS, test_binaryheap doesn't presently exercise binaryheap_free,
which seems a little sad for what's supposed to be a unit-test
module.

Of course, binaryheap_free is quite trivial and we do already
have coverage of it elsewhere. So I'm not super excited about
the omission.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-09-12 22:57:52 Re: Unexpected changes of CurrentResourceOwner and CurrentMemoryContext
Previous Message Melanie Plageman 2025-09-12 22:34:04 Re: RFC: extensible planner state