Avoid resource leak (src/test/modules/test_binaryheap/test_binaryheap.c)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52279psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 09:31 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52279_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52279_1 && git checkout t52279_1Patchset v1 (message #1) is on t52279_1
On Fri, Sep 12, 2025 at 1:54 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
Per Coverity.
Coverity reports this resource leak in test_binaryheap module.
I think that is right.Trivial patch attached.
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.
See src/backend/utils/mmgr/README
--
Robert Haas
EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
On Fri, Sep 12, 2025 at 1:54 PM Ranier Vilela <ranier.vf@gmail.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