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:32:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Patch committed.

Given the change to SRF memory management, is the following still 
necessary (or possibly even incorrect)?

in funcapi.c:
   FuncCallContext *retval = (FuncCallContext *)

   /* make sure we start with a fresh slot */
   if(retval->slot != NULL)

   return retval;

All but one of the SRFs I've tried don't seem to care, but I have one 
that is getting an assertion:

0x42029331 in kill () from /lib/i686/
(gdb) bt
#0  0x42029331 in kill () from /lib/i686/
#1  0x4202911a in raise () from /lib/i686/
#2  0x4202a8c2 in abort () from /lib/i686/
#3  0x08179ab9 in ExceptionalCondition () at assert.c:48
#4  0x0818416f in pfree (pointer=0x7f7f7f7f) at mcxt.c:470
#5  0x0806bd32 in heap_freetuple (htup=0x832bb80) at heaptuple.c:736
#6  0x080e47df in ExecClearTuple (slot=0x832b2cc) at execTuples.c:406
#7  0x0817cf49 in per_MultiFuncCall (fcinfo=0xbfffe8e0) at funcapi.c:88
#8  0x40017273 in dblink_get_pkey (fcinfo=0xbfffe8e0) at dblink.c:911

Not quite sure why yet, but I'm thinking the ExecClearTuple() is no 
longer needed/desired anyway.


In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-29 23:35:13
Subject: Re: tweaking MemSet() performance
Previous:From: Bruce MomjianDate: 2002-08-29 23:05:49
Subject: Re: @(#)Mordre Labs advisory 0x0005: Several buffer overruns

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-08-29 23:36:34
Subject: Re: [GENERAL] worried about PGPASSWORD drop
Previous:From: Justin CliftDate: 2002-08-29 23:18:04
Subject: Re: Patch for pt_BR (libpq) - part two

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