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
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) |
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) |