Re: [PATCH] Fix memory leak in pg_config

From: Andres Freund <andres(at)anarazel(dot)de>
To: Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, pgsql-hackers mailing list <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Fix memory leak in pg_config
Date: 2026-07-22 13:18:30
Message-ID: t7osyzcabasm2rz6abp2v4wcjxkn2ogm7xbrsyhle2suirlmoy@uf5zxspsb77i
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-07-22 14:54:17 +0300, Ivan Kush wrote:
> If the project policy is to ignore leaks in short-lived binaries, why
> are those known cases not listed explicitly in an LSan suppression file (for
> example, see attached patch)?
>
> Disabling leak detection globally with detect_leaks=0 also hides leaks
> that may be relevant in long-running processes. Explicit suppressions
> would document the intentionally ignored cases while preserving LSan
> coverage for the rest of the code.

Because we so far have not been using lsan. It might be worth supporting it,
but we haven't so far. You'd have to make a case for doing that on its own.

For the server lsan is probably not very helpful. Just about all allocations
in the backend are done via memory contexts, which lsan does not understand -
and can't easily be made to be understand, IIRC. Whereas we made valgrind
mostly understand memory contexts.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-07-22 13:19:39 Re: convert various variables to atomics
Previous Message Robert Haas 2026-07-22 13:12:32 Re: incremental backup issue