From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TupleTableSlot API problem |
Date: | 2009-03-30 00:29:29 |
Message-ID: | 87wsa7am52.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> For example, given some function foo(out a text, out b text) returning
>> setof record, the query select t.a, t from foo() t; follows the
>> sequence of events you describe, but it doesn't fail because
>> slot-> tts_shouldFree is false, so the original minimaltuple isn't
>> freed.
Tom> Yeah, good point. However I think that you could still get a
Tom> failure. The cases where a slot might contain a minimal tuple
Tom> are generally where we are reading out of a tuplestore or
Tom> tuplesort object, and all you have to do to get it to be a
Tom> palloc'd mintuple is to make the test case big enough so the
Tom> tuplestore has dumped to disk. (Now that I think about it, I
Tom> failed to try scaling up the test cases I did try...)
Aha; and indeed if you use select t.a, t from func() t; where the
function returns a set larger than work_mem, it does indeed fail
messily (against my -O0 --enable-cassert HEAD I just get corrupted
values for t.a, though, rather than an error). I'll try and reproduce
that on a back branch...
--
Andrew.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2009-03-30 00:58:18 | Re: TupleTableSlot API problem |
Previous Message | Tom Lane | 2009-03-30 00:24:05 | Re: TupleTableSlot API problem |