Re: [HACKERS] segfault in HEAD when too many nested functions call - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] segfault in HEAD when too many nested functions call
Date
Msg-id 25311.1501100918@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] segfault in HEAD when too many nested functions call  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] segfault in HEAD when too many nested functions call
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-07-26 15:03:37 -0400, Tom Lane wrote:
>> Hm, that seems kinda backwards to me; I was envisioning the checks
>> moving to the callees not the callers.  I think it'd end up being
>> about the same number of occurrences of CHECK_FOR_INTERRUPTS(),
>> and there would be less of a judgment call about where to put them.

> Hm, that seems a bit riskier - easy to forget one of the places where we
> might need a CFI().

I would argue the contrary.  If we put a CFI at the head of each node
execution function, then it's just boilerplate that you copy-and-paste
when you invent a new node type.  The way you've coded it here, it
seems to involve a lot of judgment calls.  That's very far from being
copy and paste, and the more different it looks from one node type
to another, the easier it will be to forget it.

> We certainly are missing a bunch of them in various nodes

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] Testlib.pm vs msys
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly