[PATCH] Memory leak in pg_config
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:t39673psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 07:57 PM.
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 t39673_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 t39673_1 && git checkout t39673_1Patchset v1 (message #1) is on t39673_1
Hi,
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
Example:
```
$ pg_config --cc
clang
=================================================================
==14521==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 368 byte(s) in 1 object(s) allocated from:
#0 0x55de20d161d9 in malloc (/usr/bin/pg_config+0xf81d9)
[...]
SUMMARY: AddressSanitizer: 2610 byte(s) leaked in 47 allocation(s).
```
The leaked memory is part of the `configdata` array which isn't freed before
exiting. It doesn't have any long term impact but it's annoying.
A similar thing happens in the `pg_config` SQL function. Since the memory
will be released at the end of the transaction, releasing it is optional but
I've done it anyway.
I'm attaching a the patch with the changes.
Greetings,
Greetings,
--
Raúl Marín Rodríguez
carto.com
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.
TBH, I do not think we should do anything about this. It has never been
project policy that short-lived programs should free everything before
exiting, and I don't think we should change that. initdb, in particular,
would need a huge amount of work to meet such a policy, and it would
really be entirely wasted effort. Just because you've configured your
tools to enforce an unreasonable policy doesn't make it a reasonable one.
regards, tom lane
On 11/14/18 3:59 PM, Tom Lane wrote:
=?UTF-8?B?UmHDumwgTWFyw61uIFJvZHLDrWd1ZXo=?= <rmrodriguez@carto.com> writes:
I've been trying to run Postgis regress tests under Clang sanitizers and one of
the issues I'm facing is the constant stream of errors during the `configure`
step coming from calls to `pg_config`.TBH, I do not think we should do anything about this. It has never been
project policy that short-lived programs should free everything before
exiting, and I don't think we should change that. initdb, in particular,
would need a huge amount of work to meet such a policy, and it would
really be entirely wasted effort. Just because you've configured your
tools to enforce an unreasonable policy doesn't make it a reasonable one.
Yeah. Incidentally we had the same discussion about initdb a few days
ago [1]/messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com, and the conclusion was pretty much exactly the same.
[1]: /messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com
/messages/by-id/3fe1e38a-fb70-6260-9300-ce67ede21c32@redhat.com
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services