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

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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)