summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2018-01-28 13:39:07 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2018-01-28 13:39:07 -0500
commit06efc5cf53b96ef5b9c10995fc7c9ec06c1b4846 (patch)
treef89b1762fec0e00ab22e9fa0dcce6811a21da639
parentfa86a32f9b3a8f44c118510cf21db6efea3a1d51 (diff)
downloadpostgresql-06efc5cf53b96ef5b9c10995fc7c9ec06c1b4846.tar.gz
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
-rw-r--r--src/backend/optimizer/plan/createplan.c3
-rw-r--r--src/backend/optimizer/prep/prepunion.c3
2 files changed, 6 insertions, 0 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c
index addb030b6b..46c29ed81e 100644
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -222,6 +222,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 0b9842baef..0741a41181 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;