Re: Why our Valgrind reports suck

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

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-05-09T16:32:30Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Briefly looking through the leaks indeed quickly found a real seeming leak,
> albeit of limited size:
> ProcessStartupPacket() does
> 	buf = palloc(len + 1);
> in TopMemoryContext() without ever freeing it.

Yeah, I saw that too.  Didn't seem worth doing anything about it
unless we make pretty massive cleanups elsewhere.

> I have wondered if we ought to have some infrastructure to tear down all
> relcache, catcache entries (and other similar things) before shutdown if
> MEMORY_CONTEXT_CHECKING is enabled. That would make it a lot easier to see
> leaks at shutdown. We certainly have had leaks in relcache etc...

I'd be content if all that stuff was shown as "still reachable".

			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.