From 88d8de430a81a3a56787d8411eeb59be634b91e1 Mon Sep 17 00:00:00 2001 From: DrewKimball Date: Mon, 15 Aug 2022 17:14:17 -0700 Subject: [PATCH] opt: use only required columns in provided ordering for project Project operators can only pass through their input ordering. However, the provided ordering may have to be remapped in order to ensure it only refers to output columns, since the `Project` can add and remove columns. The `Project` uses its `internalFDs` field to accomplish the remapping; these are constructed when the `Project` is added to the memo by combining the functional dependencies of the input and the projections. The problem occurs when transformation rules cause the input of the `Project` to "reveal" additional functional dependencies. For example, one side of a union may be eliminated and the FDs of the remaining side used in the result. This can cause the `Project` to output an ordering that is equivalent to the required ordering according to its own FDs, but which a parent operator cannot tell is equivalent because its FDs were calculated before the tranformation rule fired. This can cause panics later down the line when the provided ordering does not match up with the required ordering. In the following example, an exploration rule transforms the join into two joins unioned together, one over each disjunct. After the transformation, a normalization rule fires that removes the `t0.rowid IS NULL` side because rowids are non-null. This reveals the `t1.rowid = t0.rowid` FD, which later causes `t0.rowid` to be used in a provided ordering rather than `t1.rowid`. For the reasons mentioned above, this later causes a panic when a `Project` attempts to remap to the required `t1.rowid` ordering. ``` CREATE TABLE t0 (c0 INT); CREATE TABLE t1 (c0 INT); SELECT * FROM t0 CROSS JOIN t1 WHERE (t0.rowid IS NULL) OR (t1.rowid IN (t0.rowid)) ORDER BY t1.rowid; ``` This commit prevents the panic by making `Project` operators remap the input provided ordering to use columns from the required ordering (which are a subset of the output columns). This prevents the disparity between required and provided orderings that can cause panics down the line. In the example given above, the `t1.rowid` column would be chosen for the provided ordering because it is in the required ordering. Fixes #85393 Release note (bug fix): fixed a vulnerability in the optimizer that could cause a panic in rare cases when planning complex queries with `ORDER BY`. Release justification: low-risk bug fix --- pkg/sql/opt/ordering/project.go | 16 +++++++- pkg/sql/opt/xform/testdata/physprops/ordering | 38 +++++++++++++++++++ 2 files changed, 52 insertions(+), 2 deletions(-) diff --git a/pkg/sql/opt/ordering/project.go b/pkg/sql/opt/ordering/project.go index 62410404af24..b824cfba05ce 100644 --- a/pkg/sql/opt/ordering/project.go +++ b/pkg/sql/opt/ordering/project.go @@ -14,6 +14,7 @@ import ( "github.com/cockroachdb/cockroach/pkg/sql/opt" "github.com/cockroachdb/cockroach/pkg/sql/opt/memo" "github.com/cockroachdb/cockroach/pkg/sql/opt/props" + "github.com/cockroachdb/errors" ) func projectCanProvideOrdering(expr memo.RelExpr, required *props.OrderingChoice) bool { @@ -74,13 +75,24 @@ func projectOrderingToInput( } func projectBuildProvided(expr memo.RelExpr, required *props.OrderingChoice) opt.Ordering { - p := expr.(*memo.ProjectExpr) + // Ensure that the child provided ordering only refers to columns from the + // required ordering choice. This is necessary because there may be cases + // where the input of the Project has undergone transformations that allow it + // to "see" more functional dependencies than the original memo group. This + // can cause the child to provide an ordering that is equivalent to the + // required ordering, but which the parent Project cannot prove is equivalent + // because its FDs have less information. This can lead to a panic later on. + ordCols := required.ColSet() + if !ordCols.SubsetOf(expr.Relational().OutputCols) { + panic(errors.AssertionFailedf("expected required columns to be a subset of output columns")) + } // Project can only satisfy required orderings that refer to projected // columns; it should always be possible to remap the columns in the input's // provided ordering. + p := expr.(*memo.ProjectExpr) return remapProvided( p.Input.ProvidedPhysical().Ordering, p.InternalFDs(), - p.Relational().OutputCols, + ordCols, ) } diff --git a/pkg/sql/opt/xform/testdata/physprops/ordering b/pkg/sql/opt/xform/testdata/physprops/ordering index 88b9e31d8fb0..cec9f7ac2b62 100644 --- a/pkg/sql/opt/xform/testdata/physprops/ordering +++ b/pkg/sql/opt/xform/testdata/physprops/ordering @@ -2571,3 +2571,41 @@ project │ ├── name:2 = name:8 [outer=(2,8), fd=(2)==(8), (8)==(2)] │ └── k:7::STRING = lower(name:8) [outer=(7,8), immutable] └── 56 + +# Regression test for #85393 - use only columns from the required ordering when +# building the provided ordering for Project operators. +exec-ddl +CREATE TABLE t0_85393 (c0 INT); +---- + +exec-ddl +CREATE TABLE t1_85393 (c0 INT); +---- + +opt +SELECT * +FROM t0_85393 CROSS JOIN t1_85393 +WHERE (t0_85393.rowid IS NULL) OR (t1_85393.rowid IN (t0_85393.rowid)) +ORDER BY t1_85393.rowid; +---- +sort + ├── columns: c0:1 c0:5 [hidden: t1_85393.rowid:6!null] + ├── fd: (6)-->(5) + ├── ordering: +6 + └── project + ├── columns: t0_85393.c0:1 t1_85393.c0:5 t1_85393.rowid:6!null + ├── fd: (6)-->(5) + └── inner-join (cross) + ├── columns: t0_85393.c0:1 t0_85393.rowid:2!null t1_85393.c0:5 t1_85393.rowid:6!null + ├── key: (2,6) + ├── fd: (2)-->(1), (6)-->(5) + ├── scan t0_85393 + │ ├── columns: t0_85393.c0:1 t0_85393.rowid:2!null + │ ├── key: (2) + │ └── fd: (2)-->(1) + ├── scan t1_85393 + │ ├── columns: t1_85393.c0:5 t1_85393.rowid:6!null + │ ├── key: (6) + │ └── fd: (6)-->(5) + └── filters + └── (t0_85393.rowid:2 IS NULL) OR (t1_85393.rowid:6 = t0_85393.rowid:2) [outer=(2,6)]