From e194f13838a57a79ba6b24f6c387fe3fad4e9f9e Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 28 Jan 2018 13:39:07 -0500
Subject: [PATCH] Add stack-overflow guards in set-operation planning.
create_plan_recurse lacked any stack depth check. This is not per
our normal coding rules, but I'd supposed it was safe because earlier
planner processing is more complex and presumably should eat more
stack. But bug #15033 from Andrew Grossman shows this isn't true,
at least not for queries having the form of a many-thousand-way
INTERSECT stack.
Further testing showed that recurse_set_operations is also capable
of being crashed in this way, since it likewise will recurse to the
bottom of a parsetree before calling any support functions that
might themselves contain any stack checks. However, its stack
consumption is only perhaps a third of create_plan_recurse's.
It's possible that this particular problem with create_plan_recurse can
only manifest in 9.6 and later, since before that we didn't build a Path
tree for set operations. But having seen this example, I now have no
faith in the proposition that create_plan_recurse doesn't need a stack
check, so back-patch to all supported branches.
Discussion: https://postgr.es/m/20180127050845.28812.58244@wrigleys.postgresql.org
---
src/backend/optimizer/plan/createplan.c | 3 +++
src/backend/optimizer/prep/prepunion.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index c464d054c94..abd7b2d3cb8 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -230,6 +230,9 @@ create_plan_recurse(PlannerInfo *root, Path *best_path)
{
Plan *plan;
+ /* Guard against stack overflow due to overly complex plans */
+ check_stack_depth();
+
switch (best_path->pathtype)
{
case T_SeqScan:
diff --git a/src/backend/optimizer/prep/prepunion.c b/src/backend/optimizer/prep/prepunion.c
index 0c2bb5d51f3..c54e3251dcc 100644
--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -220,6 +220,9 @@ recurse_set_operations(Node *setOp, PlannerInfo *root,
int flag, List *refnames_tlist,
List **sortClauses, double *pNumGroups)
{
+ /* Guard against stack overflow due to overly complex setop nests */
+ check_stack_depth();
+
if (IsA(setOp, RangeTblRef))
{
RangeTblRef *rtr = (RangeTblRef *) setOp;
--
GitLab