Re: BUG #14174: Expanded-datum bug accessing freed memory

[CC'ing in the original reporter, edward.greve at gmail.com]

>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> The core of the problem here is that afn1() is returning a
 Tom> read-write pointer to the expanded object holding "r", and then
 Tom> when that's passed to afn2(), it supposes that it can take
 Tom> ownership of it as a read-write local variable; which means the
 Tom> value gets destroyed when afn2() exits.  That'd be all right
 Tom> except there's another reference to "a" still to be evaluated :-(

Yeah, I figured it was something like that, but this is the first time
I've had to look at the expanded object stuff.

 Tom> I am thinking maybe we need to have ExecProject do
 Tom> MakeExpandedObjectReadOnly on each result, rather than assuming
 Tom> that SubqueryScan is the place for that.  This would slightly
 Tom> increase the general overhead attributable to the expanded-object
 Tom> feature, which is unfortunate, but right now it's not clear that
 Tom> anything less is safe.

I concur.

 Tom> Making Result nodes do that would fix this particular instance but
 Tom> there are plenty of other node types that might appear at the top
 Tom> of a sub-select.

The Result node here is certainly an artifact of the testcase
construction; the original report (which featured about 300 lines of
view and function definitions, some of them with additional subselects,
nested in various ways) would probably have had an Agg node at the
relevant spot, and could conceivably have had any projecting node type
AFAIK.

 Tom> A possible future improvement is to teach the planner to detect
 Tom> which variables are actually multiply referenced, and force
 Tom> read-only-ness for only those values.  But that's clearly not
 Tom> something that would be reasonable to back-patch into 9.5, or even
 Tom> 9.6 at this point.

Clearly.

--
Andrew (irc:RhodiumToad)