Re: memory leak checking

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: memory leak checking
Дата
Msg-id 20190423000524.6wezmmrgczp5roxj@alap3.anarazel.de
обсуждение исходный текст
Ответ на memory leak checking  (Mikhail Bautin <mbautinpgsql@gmail.com>)
Ответы Re: memory leak checking  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2019-04-22 16:50:25 -0700, Mikhail Bautin wrote:
> What is the standard memory leak checking policy for the PostgreSQL
> codebase? I know there is some support for valgrind -- is the test suite
> being run continuously with valgrind on the build farm?

There's continuous use of valgrind on the buildfarm - but those animals
have leak checking disabled. Postgres for nearly all server allocations
uses memory contexts, which allows to bulk-free memory. There's also
plenty memory that's intentionally allocated till the end of the backend
lifetime (e.g. the various caches over the system catalogs).  Due to
that checks like valgrinds are not particularly meaningful.


> Is there any plan to support clang's AddressSanitizer?

Not for the leak portion. I use asan against the backend, after
disabling the leak check, and that's useful. Should probably set up a
proper buildfarm animal for that.


> I've seen a thread that memory leaks are allowed in initdb, because it is a
> short-lived process. Obviously they are not allowed in the database server.
> Are memory leaks allowed in the psql tool?

Leaks are allowed if they are once-per-backend type things. There's no
point in e.g. freeing information for timezone metadata, given that
it'll be used for the whole server lifetime. And there's such things in
psql too, IIRC.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mikhail Bautin
Дата:
Сообщение: memory leak checking
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: finding changed blocks using WAL scanning