Horton

Re: Why our Valgrind reports suck

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-23T01:48:24Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> [ review ]

Thanks for the comments!  I'll go through them and post an updated
version tomorrow.  The cfbot is already nagging me for a rebase
now that 0013 is moot.

>> But this is the last step to get to zero reported leaks in a run of the core
>> regression tests, so let's do it.

> I assume that's just about the core tests, not more? I.e. I can't make skink
> enable leak checking?

No, we're not there yet.  I've identified some other backend issues (in
postgres_fdw in particular), and I've not looked at frontend programs
at all.  For most frontend programs, I'm dubious how much we care.

Actually the big problem is I don't know what to do about
plperl/plpython/pltcl.  I suppose the big-hammer approach
would be to put in suppression patterns covering those,
at least till such time as someone has a better idea.

I'm envisioning this patch series as v19 work, were you
thinking we should be more aggressive?

			regards, tom lane

Commits

  1. Undo thinko in commit e78d1d6d4.

  2. Avoid leakage of zero-length arrays in partition_bounds_copy().

  3. Fix MemoryContextAllocAligned's interaction with Valgrind.

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Improve our support for Valgrind's leak tracking.

  6. Reduce leakage during PL/pgSQL function compilation.

  7. Silence Valgrind leakage complaints in more-or-less-hackish ways.

  8. Silence complaints about leaks in PlanCacheComputeResultDesc.

  9. Suppress complaints about leaks in TS dictionary loading.

  10. Suppress complaints about leaks in function cache loading.

  11. Fix per-relation memory leakage in autovacuum.

  12. Fix AlignedAllocRealloc to cope sanely with OOM.