Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group