| 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
| 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 |