-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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.4: assertion failed: estimated row count must be non-zero #53311
Comments
Ack thanks. Queries from sentry:
|
I think what may be going on is that these queries clearly have a lot of filter conditions. We prevent the selectivity of a single filter from ever going below 1e-10, but to get the overall selectivity we multiply the individual selectivities together. We only need 32 filter conditions in which the selectivity is 1e-10 for the overall selectivity to underflow the floating point representation and result in selectivity 0. The code for I was able to reproduce the error on v20.1.4 using this theory as follows:
I'm not sure if this is a problem on master (I think the multi-column stats work may prevent this problem from happening), but I'll investigate further. |
53766: filetable: switch user file payload tables to UUIDs from filename r=miretskiy,dt a=adityamaru Previously, we referenced files stored in the payload userfile table by its name. This change introduces a UUID per file. The main motivation for this change was to allow for O(1) rename of files as now we would only need to update the metadata entry, rather than every payload row. A follow-up PR will switch userfile upload to first write to a temp file and then rename only once all chunks have been successfully written. Informs: #53513 Release justification: bug fixes and low-risk updates to new functionality 53802: opt: fix internal error "estimated row count must be non-zero" r=rytaft a=rytaft Release justification: low risk, high benefit changes to existing functionality This commit fixes a rare error that could occur when a query had many highly selective filter predicates. This error occured when the estimated selectivity of a Select operator was 0. Prior to this commit, we prevented the selectivity of a single filter from ever going below 1e-10, but to get the overall selectivity we multiplied the individual selectivities together. We only needed 32 filter conditions in which the selectivity was 1e-10 for the overall selectivity to underflow the floating point representation and result in selectivity 0. This commit fixes the error by setting the selectivity to 1e-10 *after* multiplying the individual selectivities together if it is less than 1e-10. Fixes #53311 Release note (bug fix): Fixed a rare internal error that could occur during planning of queries with many highly selective predicates. 53857: geomfn: fix panic in ST_SetPoint when given empty point r=otan a=erikgrinaker Release justification: bug fixes and low-risk updates to new functionality Release note (bug fix): fix panic in `ST_SetPoint` when given empty point Resolves #53855. Co-authored-by: Aditya Maru <[email protected]> Co-authored-by: Rebecca Taft <[email protected]> Co-authored-by: Erik Grinaker <[email protected]>
Release justification: low risk, high benefit changes to existing functionality This commit fixes a rare error that could occur when a query had many highly selective filter predicates. This error occured when the estimated selectivity of a Select operator was 0. Prior to this commit, we prevented the selectivity of a single filter from ever going below 1e-10, but to get the overall selectivity we multiplied the individual selectivities together. We only needed 32 filter conditions in which the selectivity was 1e-10 for the overall selectivity to underflow the floating point representation and result in selectivity 0. This commit fixes the error by setting the selectivity to 1e-10 *after* multiplying the individual selectivities together if it is less than 1e-10. Fixes cockroachdb#53311 Release note (bug fix): Fixed a rare internal error that could occur during planning of queries with many highly selective predicates.
Just a note: I fixed this on master (before the release-20.2 branch was cut), but did not backport to 20.1 or 19.2. The backport was causing too many plan diffs, and I decided that it was not worth the potential for plan regressions to fix this extremely rare issue. |
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/1856109940/?referrer=webhooks_plugin
Panic message:
Stacktrace (expand for inline code snippets):
cockroach/pkg/sql/opt/memo/statistics_builder.go
Lines 2358 to 2360 in 12049d3
cockroach/pkg/sql/opt/memo/statistics_builder.go
Lines 764 to 766 in 12049d3
cockroach/pkg/sql/opt/memo/logical_props_builder.go
Lines 245 to 247 in 12049d3
https://github.com/cockroachdb/cockroach/blob/12049d3fe3650660e1b6abf1e522d9bb016acb88/pkg/sql/opt/memo/expr.og.go#L15684-L15686 in pkg/sql/opt/memo.(*Memo).MemoizeSelect
https://github.com/cockroachdb/cockroach/blob/12049d3fe3650660e1b6abf1e522d9bb016acb88/pkg/sql/opt/norm/factory.og.go#L1036-L1038 in pkg/sql/opt/norm.(*Factory).ConstructSelect
https://github.com/cockroachdb/cockroach/blob/12049d3fe3650660e1b6abf1e522d9bb016acb88/pkg/sql/opt/norm/factory.og.go#L664-L666 in pkg/sql/opt/norm.(*Factory).ConstructSelect
https://github.com/cockroachdb/cockroach/blob/12049d3fe3650660e1b6abf1e522d9bb016acb88/pkg/sql/opt/norm/factory.og.go#L385-L387 in pkg/sql/opt/norm.(*Factory).ConstructSelect
cockroach/pkg/sql/opt/optbuilder/select.go
Lines 1049 to 1051 in 12049d3
cockroach/pkg/sql/opt/optbuilder/select.go
Lines 922 to 924 in 12049d3
cockroach/pkg/sql/opt/optbuilder/select.go
Lines 868 to 870 in 12049d3
cockroach/pkg/sql/opt/optbuilder/select.go
Lines 841 to 843 in 12049d3
cockroach/pkg/sql/opt/optbuilder/with.go
Lines 28 to 30 in 12049d3
cockroach/pkg/sql/opt/optbuilder/select.go
Lines 840 to 842 in 12049d3
cockroach/pkg/sql/opt/optbuilder/builder.go
Lines 252 to 254 in 12049d3
cockroach/pkg/sql/opt/optbuilder/builder.go
Lines 216 to 218 in 12049d3
cockroach/pkg/sql/opt/optbuilder/builder.go
Lines 187 to 189 in 12049d3
cockroach/pkg/sql/plan_opt.go
Lines 432 to 434 in 12049d3
cockroach/pkg/sql/plan_opt.go
Lines 168 to 170 in 12049d3
cockroach/pkg/sql/conn_executor_exec.go
Lines 800 to 802 in 12049d3
cockroach/pkg/sql/conn_executor_exec.go
Lines 690 to 692 in 12049d3
cockroach/pkg/sql/conn_executor_exec.go
Lines 480 to 482 in 12049d3
cockroach/pkg/sql/conn_executor_exec.go
Lines 95 to 97 in 12049d3
cockroach/pkg/sql/conn_executor.go
Lines 1391 to 1393 in 12049d3
cockroach/pkg/sql/conn_executor.go
Lines 1320 to 1322 in 12049d3
cockroach/pkg/sql/conn_executor.go
Lines 478 to 480 in 12049d3
cockroach/pkg/sql/pgwire/conn.go
Lines 581 to 583 in 12049d3
/usr/local/go/src/runtime/asm_amd64.s#L1356-L1358 in runtime.goexit
v20.1.4
go1.13.9
The text was updated successfully, but these errors were encountered: