|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Mikhail Bautin <mbautinpgsql(at)gmail(dot)com>|
|Subject:||Re: memory leak checking|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Tomas Vondra||2019-04-23 00:13:29||Re: finding changed blocks using WAL scanning|
|Previous Message||Mikhail Bautin||2019-04-22 23:50:25||memory leak checking|