Re: TupleTableSlot API problem

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> What is happening is that ExecProject fetches the Datum value ofTom> t2.path from a TupleTableSlot that contains a
"minimaltuple"Tom> fetched from the tuplestore associated with the CTE "t".  Then,Tom> it fetches the value of the
whole-rowvariable t2.Tom> ExecEvalWholeRowVar calls ExecFetchSlotTuple, which finds thatTom> the slot doesn't contain a
regulartuple, so it callsTom> ExecMaterializeSlot, which replaces the minimal tuple with aTom> regular tuple and frees
theformer.  Now the already-fetchedTom> Datum for t2.path is pointing at freed storage.
 
Tom> In principle there ought to be a whole lot of bugs around thisTom> area, because ExecFetchSlotTuple,
ExecFetchSlotMinimalTuple,andTom> ExecFetchSlotTupleDatum all are potentially destructive of theTom> original slot
contents;furthermore there ought be be visibleTom> bugs in 8.3 and maybe before.  However, in an hour or so ofTom>
pokingat it, I've been unable to produce a failure withoutTom> using CTE syntax; it's just really hard to get the
plannertoTom> generate a whole-row-var reference in a context where theTom> 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.

If there aren't any code paths in the back branches that have
tts_shouldFree set in this context, that would explain the lack of
previously visible bugs, no? Or am I completely misunderstanding it?

-- 
Andrew (irc:RhodiumToad)