Re: Getting better results from valgrind leak tracking - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Getting better results from valgrind leak tracking
Date
Msg-id 20210329173816.wmrbbp755cdqslj6@alap3.anarazel.de
Whole thread Raw
In response to Re: Getting better results from valgrind leak tracking  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Getting better results from valgrind leak tracking  (David Rowley <dgrowleyml@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: James Hilliard
Date:
Subject: Re: [PATCH v3 1/1] Fix detection of preadv/pwritev support for OSX.
Next
From: Mark Dilger
Date:
Subject: Re: pg_amcheck contrib application