Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Tom> In principle there ought to be a whole lot of bugs around this
> Tom> area, because ExecFetchSlotTuple, ExecFetchSlotMinimalTuple, and
> Tom> ExecFetchSlotTupleDatum all are potentially destructive of the
> Tom> original slot contents; furthermore there ought be be visible
> Tom> bugs in 8.3 and maybe before. However, in an hour or so of
> Tom> poking at it, I've been unable to produce a failure without
> Tom> using CTE syntax; it's just really hard to get the planner to
> Tom> generate a whole-row-var reference in a context where the
> Tom> referenced slot might contain a minimal tuple.
> Generating the whole-row-var reference doesn't seem to be hard, it's
> doing it in a context where slot->tts_shouldFree is _already_ set that
> seems to be the issue.
> 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
> slot->freed.
Yeah, good point. However I think that you could still get a failure.
The cases where a slot might contain a minimal tuple are generally where
we are reading out of a tuplestore or tuplesort object, and all you have
to do to get it to be a palloc'd mintuple is to make the test case big
enough so the tuplestore has dumped to disk. (Now that I think about
it, I failed to try scaling up the test cases I did try...)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
