Re: [PATCH] Fix memory leak in pg_config - Mailing list pgsql-hackers

From Ivan Kush
Subject Re: [PATCH] Fix memory leak in pg_config
Date
Msg-id 5718ea33-b246-45bd-bc79-8a77731d6c5a@tantorlabs.com
Whole thread
Responses Re: [PATCH] Fix memory leak in pg_config
Re: [PATCH] Fix LISTEN startup race with direct advancement
List pgsql-hackers
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.

Regards,
Ivan


On 26-07-22 01:38, Michael Paquier wrote:
> 
> None of the changes proposed in the patch are worth caring about.  The
> only memory leaks I would care about in the frontend binaries are
> those where we could run a tool in an infinite loop where the
> non-freed would bloat.  One example of that is pg_receivewal without
> --no-loop, that could be used as a service to get WAL from a remote
> source.
> --
> Michael

-- 
Best wishes,
Ivan Kush
Tantor Labs LLC

Attachment

pgsql-hackers by date:

Previous
From: Rafia Sabih
Date:
Subject: Re: postgres_fdw: Emit message when batch_size is reduced
Next
From: Fujii Masao
Date:
Subject: Incorrect check in 037_except.pl?