Re: [HACKERS] segfault in HEAD when too many nested functions call
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] segfault in HEAD when too many nested functions call |
Дата | |
Msg-id | 20170729182807.m34ywy6l4tgylvxt@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] segfault in HEAD when too many nested functions call (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: