| 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: | Whole Thread | Raw Message | 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) |