Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management - Mailing list pgsql-patches

From Joe Conway
Subject Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management
Date
Msg-id 3D6EB2E6.1070902@joeconway.com
Whole thread Raw
In response to SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)  (Joe Conway <mail@joeconway.com>)
Responses Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> You'll need to fix that anyway because the next ExecStoreTuple will try
> to do an ExecClearTuple.  Looks like the same tuple is being freed
> twice.  Once you've handed a tuple to ExecStoreTuple it's not yours to
> free anymore; perhaps some bit of code in dblink has that wrong?

That's just it:
   0x40017273 in dblink_get_pkey (fcinfo=0xbfffe8e0) at dblink.c:911
*is*
   funcctx = SRF_PERCALL_SETUP();
which is is a macro
   #define SRF_PERCALL_SETUP() per_MultiFuncCall(fcinfo)

When I remove the call to ExecClearTuple() from per_MultiFuncCall(),
everything starts to work.

As you said, if the next ExecStoreTuple will try to do an
ExecClearTuple(), ISTM that it should be removed from
per_MultiFuncCall()/SRF_PERCALL_SETUP(). Or am I crazy?

Joe




pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)
Next
From: Gavin Sherry
Date:
Subject: Re: [HACKERS] Proposed GUC Variable