From 06b88ddf63427e1f6aeb49feb48916c3351e3380 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Mon, 17 Jul 2017 00:33:49 -0700 Subject: [PATCH 1/2] Check stack-depth when initializing executor nodes. Previously we only checked stack-depth during parse-analysis, but that's not necessarily sufficient. In v10, where targetlist SRF evaluation now is executor node based, this can indeed cause problems. It's quite possible that earlier versions are also affected in a bit different manner, or might become vulnerable due to future changes. To shore this up, add a stack-depth check to ExecInitNode(). As that's called in the same recursive manner as ExecProcNode() / MultiExecProcNode(), it should have similar stack usage as those, without incurring noticeable overhead in queries processing many rows. Author: Andres Freund Reported-By: Julien Rouhaud Discussion: https://postgr.es/m/22833.1490390175@sss.pgh.pa.us https://postgr.es/m/b0af9eaa-130c-60d0-9e4e-7a135b1e0c76@dalibo.com Backpatch: 9.2-, issue has existed for a long while --- src/backend/executor/execProcnode.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/backend/executor/execProcnode.c b/src/backend/executor/execProcnode.c index 294ad2cff9..360479d081 100644 --- a/src/backend/executor/execProcnode.c +++ b/src/backend/executor/execProcnode.c @@ -143,6 +143,15 @@ ExecInitNode(Plan *node, EState *estate, int eflags) List *subps; ListCell *l; + /* + * Make sure there's enough stack available. Check that here, rather than + * ExecProcNode() / MultiExecProcNode(), to avoid incurring overhead for + * every single tuple. The assumption making this valid is that the + * difference in stack use between node initialization and execution + * should be far less than the safety margin from check_stack_depth(). + */ + check_stack_depth(); + /* * do nothing when we get to the end of a leaf on tree. */ -- 2.13.1.392.g8d1b10321b.dirty