Re: TupleTableSlot API problem

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:58:18
Message-ID: 87prfzakt1.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:

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...)

Andrew> Aha; and indeed if you use select t.a, t from func() t; where
Andrew> the function returns a set larger than work_mem, it does
Andrew> indeed fail messily (against my -O0 --enable-cassert HEAD I
Andrew> just get corrupted values for t.a, though, rather than an
Andrew> 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2009-03-30 01:35:16 Unexpected Result in Windowing
Previous Message Andrew Gierth 2009-03-30 00:29:29 Re: TupleTableSlot API problem