Re: TupleTableSlot API problem - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: TupleTableSlot API problem
Date
Msg-id 87prfzakt1.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: TupleTableSlot API problem  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: TupleTableSlot API problem
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Yeah, good point.  However I think that you could still get aTom> failure.  The cases where a slot might contain a
minimaltupleTom> are generally where we are reading out of a tuplestore orTom> tuplesort object, and all you have to do
toget it to be aTom> palloc'd mintuple is to make the test case big enough so theTom> tuplestore has dumped to disk.
(Nowthat I think about it, ITom> failed to try scaling up the test cases I did try...)
 
Andrew> Aha; and indeed if you use select t.a, t from func() t; whereAndrew> the function returns a set larger than
work_mem,it doesAndrew> indeed fail messily (against my -O0 --enable-cassert HEAD IAndrew> just get corrupted values
fort.a, though, rather than anAndrew> error). I'll try and reproduce that on a back branch...
 

Yup, fails the same way on an --enable-cassert build of 8.3.7.

Without --enable-cassert it _appears_ to work, but this is presumably
just because the freed memory happens not to be being clobbered
immediately.

-- 
Andrew.


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: TupleTableSlot API problem
Next
From: David Fetter
Date:
Subject: Unexpected Result in Windowing