Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
>> This patch seems quite unsafe to me: it's not generally okay for
>> a plan node to return a slot that doesn't belong to it, because of
>> tuple-lifespan issues. It's possible that Result in particular
>> could do that safely, but if so we ought to hack nodeResult.c for
>> it, not the generic projection machinery.
> Concerning tuple-lifespan, almost every types of node which may
> do projection has the route for no-projInfo.
Huh? Maybe I'm missing something, but AFAICS the only place where
ExecProject is conditionally bypassed is execScan.c, that is relation
scan nodes. When execScan does skip the projection, what it returns
instead is its scan-tuple slot --- that is, a different slot that still
belongs to the scan node. So nothing changes from the standpoint of
slot ownership or lifespan. Skipping the projection step in a non-leaf
plan node would be an entirely different matter.
> From the another point of view, execution nodes may hold
> tupleslots which palloc'ed in projInfos of them just after
> receiving a result tuple from their childs. And thy are finally
> free'd in next projection on the same node or ExecEndNode() after
> the fiish of processing the entire current query. The life of the
> contents in the slots should be valid until next projection in
> upper nodes or sending the result tuple. The execution tree is
> bottom-spreaded and every node in it could not be executed under
> different ancestors, and no multi-threaded execution..
That's not so true as it used to be, with lazy evaluation of CTEs.
I just had to fix a planner bug that amounted to assuming that plan
tree execution is strictly top-down when it no longer is, so I'm
uncomfortable with adding new assumptions of that kind to the executor.
regards, tom lane
