Re: Fix memory leak when output postgres_fdw's "Relations"

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

In response to

Browse pgsql-hackers by date

  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.