Horton

Re: Getting better results from valgrind leak tracking

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-29T17:38:16Z
Lists: pgsql-hackers 
Hi,

On 2021-03-29 11:48:47 +1300, David Rowley wrote:
> I've done that in the attached.  I added the
> ParallelBlockTableScanWorkerData as a pointer field in
> HeapScanDescData and change it so we only allocate memory for it for
> just parallel scans.  The field is left as NULL for non-parallel
> scans.

LGTM.

> I've also added a pfree in heap_endscan() to free the memory when the
> pointer is not NULL. I'm hoping that'll fix the valgrind warning, but
> I've not run it to check.

Cool. I think that's a good thing to do. The leak itself should already
be fixed, and was more my fault...

commit 415ffdc2205e209b6a73fb42a3fdd6e57e16c7b2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   2021-03-18 20:50:56 -0400

    Don't run RelationInitTableAccessMethod in a long-lived context.


Greetings,

Andres Freund

Commits

  1. Improve our support for Valgrind's leak tracking.

  2. Increment xactCompletionCount during subtransaction abort.

  3. Adjust design of per-worker parallel seqscan data struct

  4. Don't leak compiled regex(es) when an ispell cache entry is dropped.

  5. Don't leak malloc'd error string in libpqrcv_check_conninfo().

  6. Don't leak malloc'd strings when a GUC setting is rejected.

  7. Don't leak rd_statlist when a relcache entry is dropped.

  8. Don't run RelationInitTableAccessMethod in a long-lived context.