Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management
Date: 2002-08-29 23:48:54
Message-ID: 3D6EB2E6.1070902@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2002-08-29 23:53:50 Re: tweaking MemSet() performance
Previous Message Tom Lane 2002-08-29 23:40:11 Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2002-08-30 00:01:32 Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)
Previous Message Tom Lane 2002-08-29 23:40:11 Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)