Skip site navigation (1) Skip section navigation (2)

Re: TupleTableSlot API problem

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane), pgsql-hackers(at)postgresql(dot)org
Subject: Re: TupleTableSlot API problem
Date: 2009-03-29 23:38:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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

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)

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-03-30 00:24:05
Subject: Re: TupleTableSlot API problem
Previous:From: Tom LaneDate: 2009-03-29 21:21:37
Subject: TupleTableSlot API problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group