From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix memory leak when output postgres_fdw's "Relations" |
Date: | 2021-07-26 02:13:14 |
Message-ID: | YP4aOiSzpuw3aiCR@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 23, 2021 at 04:20:37PM -0300, Ranier Vilela wrote:
> Maybe not yet. Valgrind may also don't understand yet.
I think that you should do things the opposite way. In short, instead
of attempting to understand first Valgrind or Coverity and then
Postgres, try to understand the internals of Postgres first and then
interpret what Valgrind or even Coverity tell you.
Tom is right. There is no point in caring about the addition some
pfree()'s in the backend code as long as they don't prove to be an
actual leak in the context where a code path is used, and nobody will
follow you on that. Some examples where this would be worth caring
about are things like tight loops leaking a bit of memory each time
these are taken, with leaks that can be easily triggered by the user
with some specific SQL commands, or even memory contexts not cleaned
up where they should, impacting some parts of the system (like the
executor, or even the planner) for a long-running analytical query.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-07-26 02:38:41 | Re: Removing "long int"-related limit on hash table sizes |
Previous Message | tanghy.fnst@fujitsu.com | 2021-07-26 02:11:29 | RE: Added schema level support for publication. |