Horton

Re: Why our Valgrind reports suck

Richard Guo <guofenglinux@gmail.com>

View thread View on postgr.es
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@lists.postgresql.org
Date: 2025-07-10T03:05:25Z
Lists: pgsql-hackers 
On Thu, Jul 10, 2025 at 3:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Now that v19 development is open, I'd like to get this work
> pushed sooner rather than later, before the patches bit-rot
> too much, and so that we can get started on follow-on work
> to remove remaining leaks.  Does anyone want to review it
> further?

I'm just skimming through the changes and happened to spot two minor
things.

In 0008:

        if (pq_mq_handle != NULL)
+       {
            shm_mq_detach(pq_mq_handle);
+           pfree(pq_mq_handle);
+       }
        pq_mq_handle = NULL;

Maybe we could move "pq_mq_handle = NULL;" inside the if branch?
Though I see we're doing it in your way on master.

In 0015:

I noticed that we're freeing the list returned from
logicalrep_workers_find().  Should we do the same for the "workers"
list in AtEOXact_LogicalRepWorkers()?


This is very useful work; I hope we can get it in soon.

Thanks
Richard

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.