>>>>> "Tom" == Tom Lane <[email protected]> writes:
Tom> What is happening is that ExecProject fetches the Datum value of Tom> t2.path from a TupleTableSlot that contains a "minimal tuple" Tom> fetched from the tuplestore associated with the CTE "t". Then, Tom> it fetches the value of the whole-row variable t2. Tom> ExecEvalWholeRowVar calls ExecFetchSlotTuple, which finds that Tom> the slot doesn't contain a regular tuple, so it calls Tom> ExecMaterializeSlot, which replaces the minimal tuple with a Tom> regular tuple and frees the former. Now the already-fetched Tom> Datum for t2.path is pointing at freed storage. 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. 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) -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
