Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opt: v20.1.0-alpha20191216: assertion failed: top-level relational expression cannot have outer columns #44724

Closed
cockroach-teamcity opened this issue Feb 4, 2020 · 2 comments · Fixed by #46227
Assignees
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. O-sentry Originated from an in-the-wild panic report.

Comments

@cockroach-teamcity
Copy link
Member

This issue was autofiled by Sentry. It represents a crash or reported error on a live cluster with telemetry enabled.

Sentry link: https://sentry.io/organizations/cockroach-labs/issues/1495879583/?referrer=webhooks_plugin

Panic message:

*errors.errorString
*safedetails.withSafeDetails: top-level relational expression cannot have outer columns: %s (1)
optimizer.go:218: *withstack.withStack (2)
*assert.withAssertionFailure
(check the extra data payloads)

Stacktrace (expand for inline code snippets):

if !root.Relational().OuterCols.Empty() {
return nil, errors.AssertionFailedf(
"top-level relational expression cannot have outer columns: %s",
in pkg/sql/opt/xform.(*Optimizer).Optimize
if _, isCanned := opc.p.stmt.AST.(*tree.CannedOptPlan); !isCanned {
if _, err := opc.optimizer.Optimize(); err != nil {
return nil, err
in pkg/sql.(*optPlanningCtx).buildExecMemo
execMemo, err := opc.buildExecMemo(ctx)
if err != nil {
in pkg/sql.(*planner).makeOptimizerPlan
log.VEvent(ctx, 2, "generating optimizer plan")
if err := planner.makeOptimizerPlan(ctx); err != nil {
log.VEventf(ctx, 1, "optimizer plan failed: %v", err)
in pkg/sql.(*connExecutor).makeExecPlan
// between here and there needs to happen even if there's an error.
err := ex.makeExecPlan(ctx, planner)
// We'll be closing the plan manually below after execution; this
in pkg/sql.(*connExecutor).dispatchToExecutionEngine
p.autoCommit = os.ImplicitTxn.Get() && !ex.server.cfg.TestingKnobs.DisableAutoCommit
if err := ex.dispatchToExecutionEngine(ctx, p, res); err != nil {
return nil, nil, err
in pkg/sql.(*connExecutor).execStmtInOpenState
} else {
ev, payload, err = ex.execStmtInOpenState(ctx, stmt, res, pinfo)
}
in pkg/sql.(*connExecutor).execStmt
stmtCtx := withStatement(ctx, ex.curStmt)
ev, payload, err = ex.execStmt(stmtCtx, curStmt, stmtRes, nil /* pinfo */)
if err != nil {
in pkg/sql.(*connExecutor).execCmd
var err error
if err = ex.execCmd(ex.Ctx()); err != nil {
if err == io.EOF || err == errDrainingComplete {
in pkg/sql.(*connExecutor).run
}()
return h.ex.run(ctx, s.pool, reserved, cancel)
}
in pkg/sql.(*Server).ServeConn
reservedOwned = false // We're about to pass ownership away.
retErr = sqlServer.ServeConn(ctx, connHandler, reserved, cancelConn)
}()
in pkg/sql/pgwire.(*conn).processCommandsAsync.func1
/usr/local/go/src/runtime/asm_amd64.s#L1336-L1338 in runtime.goexit

pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).Optimize at line 218
pkg/sql/plan_opt.go in pkg/sql.(*optPlanningCtx).buildExecMemo at line 424
pkg/sql/plan_opt.go in pkg/sql.(*planner).makeOptimizerPlan at line 162
pkg/sql/conn_executor_exec.go in pkg/sql.(*connExecutor).makeExecPlan at line 743
pkg/sql/conn_executor_exec.go in pkg/sql.(*connExecutor).dispatchToExecutionEngine at line 626
pkg/sql/conn_executor_exec.go in pkg/sql.(*connExecutor).execStmtInOpenState at line 417
pkg/sql/conn_executor_exec.go in pkg/sql.(*connExecutor).execStmt at line 98
pkg/sql/conn_executor.go in pkg/sql.(*connExecutor).execCmd at line 1250
pkg/sql/conn_executor.go in pkg/sql.(*connExecutor).run at line 1179
pkg/sql/conn_executor.go in pkg/sql.(*Server).ServeConn at line 450
pkg/sql/pgwire/conn.go in pkg/sql/pgwire.(*conn).processCommandsAsync.func1 at line 584
/usr/local/go/src/runtime/asm_amd64.s in runtime.goexit at line 1337
Tag Value
Cockroach Release v20.1.0-alpha20191216
Cockroach SHA: e9e2a80
Platform darwin amd64
Distribution CCL
Environment v20.1.0-alpha20191216
Command demo
Go Version go1.12.12
# of CPUs 8
# of Goroutines 176
@cockroach-teamcity cockroach-teamcity added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. O-sentry Originated from an in-the-wild panic report. labels Feb 4, 2020
@yuzefovich yuzefovich changed the title sentry: *errors.errorString *safedetails.withSafeDetails: top-level relational expression cannot have outer columns: %s (1) optimizer.go:218: *withstack.withStack (2) *assert.withAssertionFailure (check the extra data payloads) sentry: opt: assertion failed: top-level relational expression cannot have outer columns Mar 14, 2020
@yuzefovich
Copy link
Member

The anonymized query is SELECT _, _, _, _, _ FROM (SELECT _ AS _, _, _ - (_ * _) AS _ FROM _) AS _ JOIN LATERAL (SELECT _, sum(_._) AS _ FROM _ WHERE ((_ = _) AND (_._ = _._)) AND (_._ > _)) AS _ ON _.

cc @RaduBerinde @rytaft

@yuzefovich yuzefovich changed the title sentry: opt: assertion failed: top-level relational expression cannot have outer columns opt: v20.1.0-alpha20191216: assertion failed: top-level relational expression cannot have outer columns Mar 14, 2020
@rytaft
Copy link
Collaborator

rytaft commented Mar 16, 2020

I can reproduce this. With the Movr schema, the following query triggers this error:

SELECT *
  FROM (SELECT 1 AS one, id FROM users) AS u
  JOIN LATERAL (
        SELECT rider_id, sum(one) AS rev FROM rides
       ) AS r ON u.id = rider_id;

@rytaft rytaft self-assigned this Mar 16, 2020
craig bot pushed a commit that referenced this issue Mar 20, 2020
45668: ui: Redesign Events section on Metrics page r=dhartunian a=koorosh

Resolves: #45402 

Current change is required to fit date and
event message after date format was changed.
Before, Events section had two columns and it
could not fit full date string in the second
column without wrapping to several rows what
made it not readable.

Now, instead of showing two separate columns,
date of event is displayed under event message
and both event name and date can occupy entire
width of events table.

Number of events to show on Metrics page is
decreased from 10 to 5.

Release justification: bug fixes and low-risk updates to new functionality

<img width="1437" alt="Screenshot 2020-03-19 at 15 13 59 1" src="https://user-images.githubusercontent.com/3106437/77073262-aab44180-69f7-11ea-866d-3a16b97d0349.png">

<img width="570" alt="Screenshot 2020-03-19 at 15 19 42" src="https://user-images.githubusercontent.com/3106437/77073234-a0924300-69f7-11ea-9ed6-d13d91cacea0.png">


46227: opt: fix some aggregate scoping issues r=rytaft a=rytaft

Prior to this commit, some aggregate functions were either incorrectly
rejected or incorrectly accepted when they were scoped at a higher
level than their position in the query. For example, aggregate functions
are not normally allowed in `WHERE`, but if the aggregate is actually scoped
at a higher level, then the aggregate should be allowed. Prior to this
commit, these aggregate functions were rejected and caused an error.

This commit fixes the issue by validating the context of the aggregate's
scope rather than the aggregate's position in the query. In order to
avoid adding another field to the scope struct, this commit re-uses
the existing `context` field which was previously only used for error
messages. To make comparisons more efficient, the field is now an enum
rather than a string.

Fixes #44724
Fixes #45838
Fixes #30652

Release justification: This bug fix is a low risk, high benefit change
to existing functionality, since it fixes internal errors and increases
compatibility with Postgres.

Release note (bug fix): Fixed an internal error that could occur when
an aggregate inside the right-hand side of a LATERAL join was scoped at
the level of the left-hand side.

Release note (bug fix): Fixed an error that incorrectly occurred when
an aggregate was used inside the WHERE or ON clause of a subquery but
was scoped at an outer level of the query.

Co-authored-by: Andrii Vorobiov <[email protected]>
Co-authored-by: Rebecca Taft <[email protected]>
@craig craig bot closed this as completed in ad05c3b Mar 20, 2020
rytaft added a commit to rytaft/cockroach that referenced this issue Mar 25, 2020
Prior to this commit, some aggregate functions were either incorrectly
rejected or incorrectly accepted when they were scoped at a higher
level than their position in the query. For example, aggregate functions
are not normally allowed in WHERE, but if the aggregate is actually scoped
at a higher level, then the aggregate should be allowed. Prior to this
commit, these aggregate functions were rejected and caused an error.

This commit fixes the issue by validating the context of the aggregate's
scope rather than the aggregate's position in the query. In order to
avoid adding another field to the scope struct, this commit re-uses
the existing `context` field which was previously only used for error
messages. To make comparisons more efficient, the field is now an enum
rather than a string.

Fixes cockroachdb#44724
Fixes cockroachdb#45838
Fixes cockroachdb#30652

Release justification: This bug fix is a low risk, high benefit change
to existing functionality, since it fixes internal errors and increases
compatibility with Postgres.

Release note (bug fix): Fixed an internal error that could occur when
an aggregate inside the right-hand side of a LATERAL join was scoped at
the level of the left-hand side.

Release note (bug fix): Fixed an error that incorrectly occurred when
an aggregate was used inside the WHERE or ON clause of a subquery but
was scoped at an outer level of the query.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. O-sentry Originated from an in-the-wild panic report.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants