From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: segfault in HEAD when too many nested functions call |
Date: | 2017-07-29 18:28:07 |
Message-ID: | 20170729182807.m34ywy6l4tgylvxt@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-07-29 14:20:32 -0400, Tom Lane wrote:
> Here's a reviewed version of this patch.
Thanks!
> * I think you put ExecScan's CFI in the wrong place; AFAICT yours
> only covers its fast path.
Sure - but the old path already has a CFI? And it has to be inside the
loop, because well, the loop ;).
> * I think ExecAgg needs a CFI at the head, just to be sure it's hit
> in any path through that.
Yep, makes esense.
> * 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.
Ok, I can live with that.
> * You missed ExecLockRows altogether.
Well, it directly calls the next ExecProcNode(), so I didn't think it
was necessary. One of the aforementioned judgement calls. But I'm
perfectly happy to have one there.
Thanks,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2017-07-29 19:07:05 | Re: Causal reads take II |
Previous Message | Tom Lane | 2017-07-29 18:20:32 | Re: segfault in HEAD when too many nested functions call |