Re: Valgrind - showing memory leaks

Yasir <yasir.hussain.shah@gmail.com>

From: Yasir <yasir.hussain.shah@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-05-08T19:57:19Z
Lists: pgsql-hackers
On Thu, May 8, 2025 at 7:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yasir <yasir.hussain.shah@gmail.com> writes:
> > I believe that the valgrind should not report any memory leaks in such
> > simple/common commands. What am I doing wrong here?
>
> I think you are vastly overestimating both the intelligence of
> valgrind, and our level of concern about minor one-time leaks.
> Most of these are probably not really leaks at all, but failure
> on valgrind's part to notice the relevant pointers.  Moreover,
> almost all are blamed on catcache setup, which is a one-time
> operation; so even if it is losing track of some allocations,
> it's not likely to be something worth worrying about.
>
> Alvaro seems to think CheckNNConstraintFetch is worth taking
> a second look at, and maybe he's right, but the amount of
> storage involved there seems unexciting too.
>
>                         regards, tom lane
>

Makes sense, these look like valgrind false positives tied to long-lived
allocations.
Since Alvaro flagged CheckNNConstraintFetch, I’ll leave it to him to take a
closer look if he still thinks it’s worth digging into.

Best,
Yasir
Data Bene

Commits

  1. relcache: Avoid memory leak on tables with no CHECK constraints

  2. Silence compilers about extractNotNullColumn()