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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)
Date: 2002-08-29 23:40:11
Message-ID: 13672.1030664411@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Joe Conway <mail(at)joeconway(dot)com> writes:
> Given the change to SRF memory management, is the following still 
> necessary (or possibly even incorrect)?

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

I don't think it was ever necessary... but there's nothing wrong with
it either.

> 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/libc.so.6
> (gdb) bt
> #0  0x42029331 in kill () from /lib/i686/libc.so.6
> #1  0x4202911a in raise () from /lib/i686/libc.so.6
> #2  0x4202a8c2 in abort () from /lib/i686/libc.so.6
> #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.

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?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Joe ConwayDate: 2002-08-29 23:48:54
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management
Previous:From: Bruce MomjianDate: 2002-08-29 23:35:13
Subject: Re: tweaking MemSet() performance

pgsql-patches by date

Next:From: Joe ConwayDate: 2002-08-29 23:48:54
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about memory management
Previous:From: Bruce MomjianDate: 2002-08-29 23:36:34
Subject: Re: [GENERAL] worried about PGPASSWORD drop

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