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-30 00:46:24
Message-ID: 15535.1030668384@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Joe Conway <mail(at)joeconway(dot)com> writes:
> I have found the smoking gun, however. I had changed this function from 
> returning setof text, to returning setof 
> two_column_named_composite_type. *However*. I had not dropped and 
> recreated the function with the proper declaration. Once I redeclared 
> the function properly, the coredump went away, even with current 
> per_MultiFuncCall() code.

Ah.  I think the changes I just committed would have helped:
nodeFunctionscan.c now runs a tupledesc_mismatch() check regardless of
whether it thinks the function returns RECORD or not.

>> But I suspect that what we want to do is take management of the tuples
>> away from the Slot: pass should_free = FALSE to ExecStoreTuple in the
>> TupleGetDatum macro.  The ClearTuple call *is* appropriate when you do
>> that, because it will reset the Slot to empty rather than leaving it
>> containing a dangling pointer to a long-since-freed tuple.

> OK. I'll make that change and leave ExecClearTuple() in 
> per_MultiFuncCall(). Sound like a plan?

First let's see if we can figure out why the code is failing to fail
as it stands.  The fact that it's not dumping core says there's
something we don't understand yet ...

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-30 01:20:14
Subject: Re: tweaking MemSet() performance
Previous:From: Tom LaneDate: 2002-08-30 00:42:28
Subject: Re: [HACKERS] Proposed GUC Variable

pgsql-patches by date

Next:From: Tatsuo IshiiDate: 2002-08-30 01:25:48
Subject: Re: SRF memory mgmt patch
Previous:From: Tom LaneDate: 2002-08-30 00:42:28
Subject: Re: [HACKERS] Proposed GUC Variable

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