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)
