Re: Why our Valgrind reports suck

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Why our Valgrind reports suck
Date: 2025-05-12 14:23:56
Message-ID: 37442.1747059836@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre(at)kurilemu(dot)de> writes:
> On 2025-May-11, Tom Lane wrote:
>> 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.

Interesting.

> He actually blames it on relcache, but who knows how correct that is.

I would not be surprised if the relcache is bloated too, but Valgrind
wouldn't think that's a leak. I wonder if it'd be worth setting up
a mechanism for autovacuum to drop the relcache entry for a table
once it's done with it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Orlov 2025-05-12 14:25:00 Re: [PATCH] Fix replica identity mismatch for partitioned tables with publish_via_partition_root
Previous Message Álvaro Herrera 2025-05-12 14:13:37 Re: Why our Valgrind reports suck