database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-07 00:36:50 +03:00
Code Activity

Fix possible crash with nested SubLinks.

Browse Source 
An expression such as WHERE (... x IN (SELECT ...) ...) IN (SELECT ...)
could produce an invalid plan that results in a crash at execution time,
if the planner attempts to flatten the outer IN into a semi-join.
This happens because convert_testexpr() was not expecting any nested
SubLinks and would wrongly replace any PARAM_SUBLINK Params belonging
to the inner SubLink.  (I think the comment denying that this case could
happen was wrong when written; it's certainly been wrong for quite a long
time, since very early versions of the semijoin flattening logic.)

Per report from Teodor Sigaev.  Back-patch to all supported branches.
This commit is contained in:
Tom Lane
2013-12-10 16:10:20 -05:00
parent 0ec530625f
commit 9d2e07fecd
3 changed files with 62 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
src/backend/optimizer/plan/subselect.c
View File

@ -856,11 +856,6 @@ generate_subquery_vars(PlannerInfo *root, List *tlist, Index varno)
* with Params or Vars representing the results of the sub-select. The
* nodes to be substituted are passed in as the List result from
* generate_subquery_params or generate_subquery_vars.
*
* The given testexpr has already been recursively processed by
* process_sublinks_mutator. Hence it can no longer contain any
* PARAM_SUBLINK Params for lower SubLink nodes; we can safely assume that
* any we find are for our own level of SubLink.
*/
static Node *
convert_testexpr(PlannerInfo *root,
@ -899,6 +894,28 @@ convert_testexpr_mutator(Node *node,
param->paramid - 1));
}
}
if (IsA(node, SubLink))
{
/*
* If we come across a nested SubLink, it is neither necessary nor
* correct to recurse into it: any PARAM_SUBLINKs we might find inside
* belong to the inner SubLink not the outer. So just return it as-is.
*
* This reasoning depends on the assumption that nothing will pull
* subexpressions into or out of the testexpr field of a SubLink, at
* least not without replacing PARAM_SUBLINKs first. If we did want
* to do that we'd need to rethink the parser-output representation
* altogether, since currently PARAM_SUBLINKs are only unique per
* SubLink not globally across the query. The whole point of
* replacing them with Vars or PARAM_EXEC nodes is to make them
* globally unique before they escape from the SubLink's testexpr.
*
* Note: this can't happen when called during SS_process_sublinks,
* because that recursively processes inner SubLinks first. It can
* happen when called from convert_ANY_sublink_to_join, though.
*/
return node;
}
return expression_tree_mutator(node,
convert_testexpr_mutator,
(void *) context);