Horton

Re: Why our Valgrind reports suck

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-05-09T15:50:45Z
Lists: pgsql-hackers 
Hi,

On 2025-05-09 11:29:43 -0400, Andres Freund wrote:
> We currently don't reset TopMemoryContext at exit, which, obviously, does
> massively increase the number of leaks. But OTOH, without that there's not a
> whole lot of value in the leak check...

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.


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...

Greetings,

Andres Freund

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.