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:07:35
Message-ID: 14452.1030666055@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Joe Conway <mail(at)joeconway(dot)com> writes:
> 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?

Actually ... on second thought ...

I bet the real issue here is that we have a long-lived TupleTableSlot
pointing at a short-lived tuple.  (I assume you're just forming the
tuple in the function's working context, no?)

When ExecClearTuple is called on the next time through, it tries to
pfree a tuple that has already been recycled along with the rest of
the short-term context.  Result: coredump.

However, if that were the story then *none* of the SRFs returning
tuple should work, and they do.  So I'm still confused.

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2002-08-30 00:08:45
Subject: Re: tweaking MemSet() performance
Previous:From: Gavin SherryDate: 2002-08-30 00:04:25
Subject: Re: [HACKERS] Proposed GUC Variable

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-08-30 00:10:32
Subject: Re: [HACKERS] Proposed GUC Variable
Previous:From: Gavin SherryDate: 2002-08-30 00:04:25
Subject: Re: [HACKERS] Proposed GUC Variable

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