Thread: Re: Getting better results from valgrind leak tracking

Re: Getting better results from valgrind leak tracking

From
David Rowley
Date:
On Wed, 17 Mar 2021 at 15:31, Andres Freund <andres@anarazel.de> wrote:
> I'm a bit confused about the precise design of rs_private /
> ParallelBlockTableScanWorkerData, specifically why it's been added to
> TableScanDesc, instead of just adding it to HeapScanDesc? And why is it
> allocated unconditionally, instead of just for parallel scans?

That's a good point. In hindsight, I didn't spend enough effort
questioning that design in the original patch.  I see now that the
rs_private field makes very little sense as we can just store what's
private to heapam in HeapScanDescData.

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.

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.

David

Attachment

Re: Getting better results from valgrind leak tracking

From
Andres Freund
Date:
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



Re: Getting better results from valgrind leak tracking

From
David Rowley
Date:
On Tue, 30 Mar 2021 at 06:38, Andres Freund <andres@anarazel.de> wrote:
> 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.

Thanks for having a look.

Pushed.

David