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

Re: SRF memory mgmt patch (was [HACKERS] Concern about

From: Joe Conway <mail(at)joeconway(dot)com>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about
Date: 2002-08-30 18:51:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Joe Conway wrote:
> Joe Conway wrote:
>> I'm looking at this now. I suspect the easy fix is to remove 
>> ExecClearTuple from per_MultiFuncCall, but I'll try to understand 
>> what's going on first.
> On second thought, *all* functions failing is what you expected, right 
> Tom? I just changed TupleGetDatum() as we discussed:
> #define TupleGetDatum(_slot, _tuple) \
>   PointerGetDatum(ExecStoreTuple(_tuple, _slot, InvalidBuffer, false))
> and now everything works again. Is this the preferred fix and/or is it 
> worth spending more time to dig into this?

Here is a patch with the above mentioned fix. It also has an addition to 
rangefuncs.sql and rangefuncs.out to ensure a C language table function 
gets tested. I did this by adding
   SELECT * FROM pg_settings WHERE name LIKE 'enable%';
to the test. I think this should produce reasonably stable results, but 
obviously will require some maintenance if we add/remove a GUC variable 
matching this criteria. Alternative suggestions welcomed, but if there 
are no objections, please commit.



Attachment: tablefunc-fix.1.patch
Description: text/plain (2.2 KB)

In response to


pgsql-hackers by date

Next:From: Laurette CisnerosDate: 2002-08-30 18:57:17
Subject: source code indexer
Previous:From: Matthew T. OConnorDate: 2002-08-30 18:43:38
Subject: Re: [HACKERS] pgaccess - where to store the own data

pgsql-patches by date

Next:From: Joe ConwayDate: 2002-08-30 19:05:34
Subject: update to contrib/dblink
Previous:From: Joe ConwayDate: 2002-08-30 17:51:35
Subject: Re: SRF memory mgmt patch (was [HACKERS] Concern about

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