Horton

Re: Why our Valgrind reports suck

Álvaro Herrera <alvherre@kurilemu.de>

View thread View on postgr.es
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-05-12T14:13:37Z
Lists: pgsql-hackers 
On 2025-May-11, Tom Lane wrote:

> Okay, here is a patch series that updates the
> 0001-Make-memory-contexts-themselves-more-visible-to-valg.patch
> patch you posted in that thread, and makes various follow-up
> fixes that either fix or paper over various leaks.

Wow, that's a lot of extra fixes.  I did a quick test run with all
patches save the last, then run tests "test_setup plpgsql tablespace" to
see if I'd get a leak report about plpgsql (to verify the setup was
correct), and I did.  Rerunning after applying that patch silences what
seems to be most of them.

One source of leaks still present is LLVM.  It's not large numbers,

140303.log:==00:00:12:42.244 140303==      possibly lost: 18,336 bytes in 207 blocks
140442.log:==00:00:13:43.070 140442==      possibly lost: 18,456 bytes in 210 blocks
140729.log:==00:00:16:09.802 140729==      possibly lost: 64,120 bytes in 840 blocks
140892.log:==00:00:17:39.300 140892==      possibly lost: 18,128 bytes in 202 blocks
141001.log:==00:00:18:31.631 141001==      possibly lost: 18,128 bytes in 202 blocks
141031.log:==00:00:19:03.528 141031==      possibly lost: 64,232 bytes in 717 blocks
141055.log:==00:00:20:11.536 141055==      possibly lost: 18,128 bytes in 202 blocks
141836.log:==00:00:29:10.344 141836==    definitely lost: 29,666 bytes in 3,175 blocks
141836.log:==00:00:29:10.344 141836==    indirectly lost: 13,977 bytes in 1,138 blocks
142061.log:==00:00:32:26.264 142061==      possibly lost: 18,128 bytes in 202 blocks

(The installcheck run is still going, but 90 tests in, those are the
only reports of ~10kB or more).


> In particular, I had not realized that autovacuum
> leaks a nontrivial amount of memory per relation processed (cf 0009),
> and apparently has done for a few releases now.  This is horrid in
> databases with many tables, and I'm surprised that we've not gotten
> complaints about it.

In PGConf Germany we got a lightning talk[1] that reported a problem
that might be explained by this: with 10 million of relations, the OOM
killer gets invoked on autovacuum workers on the reported case, so
essentially autovacuum doesn't work at all.  So clearly there is somebody
that would appreciate that this problem is fixed.

He actually blames it on relcache, but who knows how correct that is.
Not much to see on the slides other than they turn to vacuumdb instead,
but they're here:

[1] https://www.postgresql.eu/events/pgconfde2025/sessions/session/6625/slides/681/06%20-%20LT%20-%20Jonas%20Marasus%20-%20War%20Story%20How%20Big%20Is%20Too%20Big%20For%20a%20Schema.pdf

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Computing is too important to be left to men." (Karen Spärck Jones)

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.