Re: segfault in HEAD when too many nested functions call

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2017-07-26 16:28:38 -0400, Tom Lane wrote:
>> It's certainly possible that there are long-running loops not involving
>> any ExecProcNode recursion at all, but that would be a bug independent
>> of this issue. The CFI in ExecProcNode itself can be replaced exactly
>> either by asking all callers to do it, or by asking all callees to do it.
>> I think the latter is going to be more uniform and harder to screw up.

> Looks a bit better. Still a lot of judgement-y calls tho, e.g. when one
> node function just calls the next, or when there's loops etc. I found
> a good number of missing CFIs...

> What do you think?

Here's a reviewed version of this patch. Differences from yours:

* I think you put ExecScan's CFI in the wrong place; AFAICT yours
only covers its fast path.

* I think ExecAgg needs a CFI at the head, just to be sure it's hit
in any path through that.

* I agree that putting CFI inside ExecHashJoin's state machine loop
is a good idea, because it might have to trawl through quite a lot of
a batch file before finding a returnable tuple. But I think in merge
and nestloop joins it's sufficient to put one CFI at the head. Neither
of those cases can do very much processing without invoking a child
node, where a CFI will happen.

* You missed ExecLockRows altogether.

* I added some comments and cosmetic tweaks.

regards, tom lane