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.

Sign up for GitHub

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

Jump to bottom

opt: v23.1.12: span must be fully contained in the bucket #124181

Closed
cockroach-sentry opened this issue May 14, 2024 · 3 comments · Fixed by #124603
Closed

opt: v23.1.12: span must be fully contained in the bucket #124181

cockroach-sentry opened this issue May 14, 2024 · 3 comments · Fixed by #124603
Assignees
@michae2
Labels
branch-release-20.2 Used to mark technical advisories for 20.2 branch-release-21.1 Used to mark technical advisories for 21.1 branch-release-21.2 Used to mark technical advisories for 21.2 branch-release-22.1 Used to mark release blockers and technical advisories for 22.1 branch-release-22.2 Used to mark release blockers and technical advisories for 22.2 branch-release-23.1 Used to mark GA and release blockers and technical advisories for 23.1 branch-release-23.2 Used to mark GA and release blockers and technical advisories for 23.2 branch-release-24.1 Used to mark GA and release blockers and technical advisories for 24.1 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. O-support Would prevent or help troubleshoot a customer escalation - bugs, missing observability/tooling, docs P-1 Issues/test failures with a fix SLA of 1 month T-sql-queries SQL Queries Team

Comments

@cockroach-sentry
Copy link
Collaborator

cockroach-sentry commented May 14, 2024 •
edited by cockroach-jira-scripts
Loading

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

Sentry Link: https://cockroach-labs.sentry.io/issues/5351250767/?referrer=webhooks_plugin

Panic Message:

histogram.go:694: span must be fully contained in the bucket
(1) assertion failure
Wraps: (2) attached stack trace
  -- stack trace:
  | github.com/cockroachdb/cockroach/pkg/sql/opt/props.getFilteredBucket
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/props/histogram.go:694
  | github.com/cockroachdb/cockroach/pkg/sql/opt/props.(*Histogram).filter
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/props/histogram.go:341
  | github.com/cockroachdb/cockroach/pkg/sql/opt/props.(*Histogram).Filter
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/props/histogram.go:407
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*statisticsBuilder).updateHistogram
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/statistics_builder.go:3637
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*statisticsBuilder).applyIndexConstraint.func1
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/statistics_builder.go:3401
  | github.com/cockroachdb/cockroach/pkg/sql/opt.ColSet.ForEach.func1
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/colset.go:83
  | github.com/cockroachdb/cockroach/pkg/util/intsets.Fast.ForEach
  | 	github.com/cockroachdb/cockroach/pkg/util/intsets/fast.go:154
  | github.com/cockroachdb/cockroach/pkg/sql/opt.ColSet.ForEach
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/colset.go:83
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*statisticsBuilder).applyIndexConstraint
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/statistics_builder.go:3399
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*statisticsBuilder).constrainScan
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/statistics_builder.go:948
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*statisticsBuilder).buildScan
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/statistics_builder.go:859
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*logicalPropsBuilder).buildScanProps
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/memo/logical_props_builder.go:186
  | github.com/cockroachdb/cockroach/pkg/sql/opt/memo.(*Memo).MemoizeScan
  | 	github.com/cockroachdb/cockroach/bazel-out/k8-opt/bin/pkg/sql/opt/memo/expr.og.go:20146
  | github.com/cockroachdb/cockroach/pkg/sql/opt/norm.(*Factory).ConstructScan
  | 	github.com/cockroachdb/cockroach/bazel-out/k8-opt/bin/pkg/sql/opt/norm/factory.og.go:456
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*indexScanBuilder).Build
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/index_scan_builder.go:249
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*CustomFuncs).GenerateConstrainedScans.func1
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/select_funcs.go:505
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*scanIndexIter).ForEachStartingAfter
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/scan_index_iter.go:305
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*scanIndexIter).ForEach
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/scan_index_iter.go:208
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*CustomFuncs).GenerateConstrainedScans
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/select_funcs.go:441
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*explorer).exploreSelect
  | 	github.com/cockroachdb/cockroach/bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go:259
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*explorer).exploreGroupMember
  | 	github.com/cockroachdb/cockroach/bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go:24
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*explorer).exploreGroup
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/explorer.go:185
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).optimizeGroup
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:536
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).optimizeEnforcer
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:717
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).enforceProps
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:668
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).optimizeGroupMember
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:563
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).optimizeGroup
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:523
  | github.com/cockroachdb/cockroach/pkg/sql/opt/xform.(*Optimizer).Optimize
  | 	github.com/cockroachdb/cockroach/pkg/sql/opt/xform/optimizer.go:269
  | github.com/cockroachdb/cockroach/pkg/sql.(*optPlanningCtx).reuseMemo
  | 	github.com/cockroachdb/cockroach/pkg/sql/plan_opt.go:507
  | github.com/cockroachdb/cockroach/pkg/sql.(*optPlanningCtx).buildExecMemo
  | 	github.com/cockroachdb/cockroach/pkg/sql/plan_opt.go:537
  | github.com/cockroachdb/cockroach/pkg/sql.(*planner).makeOptimizerPlan
  | 	github.com/cockroachdb/cockroach/pkg/sql/plan_opt.go:240
  | github.com/cockroachdb/cockroach/pkg/sql.(*connExecutor).makeExecPlan
  | 	github.com/cockroachdb/cockroach/pkg/sql/conn_executor_exec.go:2028
Wraps: (3) span must be fully contained in the bucket
Error types: (1) *assert.withAssertionFailure (2) *withstack.withStack (3) *errutil.leafError
-- report composition:
*errutil.leafError: span must be fully contained in the bucket
histogram.go:694: *withstack.withStack (top exception)
*assert.withAssertionFailure
Stacktrace (expand for inline code snippets):

cockroach/pkg/sql/conn_executor_exec.go

Lines 2027 to 2029 in d7e9824

func (ex *connExecutor) makeExecPlan(ctx context.Context, planner *planner) error {
if err := planner.makeOptimizerPlan(ctx); err != nil {
log.VEventf(ctx, 1, "optimizer plan failed: %v", err)

cockroach/pkg/sql/plan_opt.go

Lines 239 to 241 in d7e9824

execMemo, err := opc.buildExecMemo(ctx)
if err != nil {

cockroach/pkg/sql/plan_opt.go

Lines 536 to 538 in d7e9824

opc.log(ctx, "reusing cached memo")
memo, err := opc.reuseMemo(ctx, prepared.Memo)
return memo, err

cockroach/pkg/sql/plan_opt.go

Lines 506 to 508 in d7e9824

}
if _, err := opc.optimizer.Optimize(); err != nil {
return nil, err

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 268 to 270 in d7e9824

rootProps := o.mem.RootProps()
o.optimizeGroup(root, rootProps)

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 522 to 524 in d7e9824

// Optimize the group member with respect to the required properties.
memberOptimized := o.optimizeGroupMember(state, member, required)

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 562 to 564 in d7e9824

// of requiring one of the merge join children to be sorted.
fullyOptimized = o.enforceProps(state, member, required)

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 667 to 669 in d7e9824

}
return o.optimizeEnforcer(state, getEnforcer, required, member)
}

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 716 to 718 in d7e9824

memberProps := BuildChildPhysicalProps(o.mem, enforcer, 0, enforcerProps)
innerState := o.optimizeGroup(member, memberProps)
fullyOptimized = innerState.fullyOptimized

cockroach/pkg/sql/opt/xform/optimizer.go

Lines 535 to 537 in d7e9824

// other expressions in this group.
if o.shouldExplore(required) && !o.explorer.exploreGroup(grp, required).fullyExplored {
fullyOptimized = false

cockroach/pkg/sql/opt/xform/explorer.go

Lines 184 to 186 in d7e9824

if memberExplored := e.exploreGroupMember(state, member, i, required); memberExplored {
// No more rules can ever match this expression, so skip it in

https://github.com/cockroachdb/cockroach/blob/d7e9824b4cd6ebf7a8548156f2a772ae6648257d/bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go#L23-L25
https://github.com/cockroachdb/cockroach/blob/d7e9824b4cd6ebf7a8548156f2a772ae6648257d/bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go#L258-L260

cockroach/pkg/sql/opt/xform/select_funcs.go

Lines 440 to 442 in d7e9824

iter.Init(c.e.evalCtx, c.e.f, c.e.mem, &c.im, scanPrivate, explicitFilters, rejectInvertedIndexes)
iter.ForEach(func(index cat.Index, filters memo.FiltersExpr, indexCols opt.ColSet, isCovering bool, constProj memo.ProjectionsExpr) {

cockroach/pkg/sql/opt/xform/scan_index_iter.go

Lines 207 to 209 in d7e9824

func (it *scanIndexIter) ForEach(f enumerateIndexFunc) {
it.ForEachStartingAfter(cat.PrimaryIndex-1, f)
}

cockroach/pkg/sql/opt/xform/scan_index_iter.go

Lines 304 to 306 in d7e9824

f(index, filters, indexCols, isCovering, constProj)

cockroach/pkg/sql/opt/xform/select_funcs.go

Lines 504 to 506 in d7e9824

sb.Build(grp)
})

cockroach/pkg/sql/opt/xform/index_scan_builder.go

Lines 248 to 250 in d7e9824

input := b.f.ConstructScan(&b.scanPrivate)

https://github.com/cockroachdb/cockroach/blob/d7e9824b4cd6ebf7a8548156f2a772ae6648257d/bazel-out/k8-opt/bin/pkg/sql/opt/norm/factory.og.go#L455-L457
https://github.com/cockroachdb/cockroach/blob/d7e9824b4cd6ebf7a8548156f2a772ae6648257d/bazel-out/k8-opt/bin/pkg/sql/opt/memo/expr.og.go#L20145-L20147

cockroach/pkg/sql/opt/memo/logical_props_builder.go

Lines 185 to 187 in d7e9824

if !b.disableStats {
b.sb.buildScan(scan, rel)
}

cockroach/pkg/sql/opt/memo/statistics_builder.go

Lines 858 to 860 in d7e9824

c.InitSingleSpan(&keyCtx, scan.Constraint.Spans.Get(i))
sb.constrainScan(scan, &c, pred, relProps, &spanStats)
spanStatsUnion.UnionWith(&spanStats)

cockroach/pkg/sql/opt/memo/statistics_builder.go

Lines 947 to 949 in d7e9824

if constraint != nil {
constrainedColsLocal, histColsLocal := sb.applyIndexConstraint(constraint, scan, relProps, s)
constrainedCols.UnionWith(constrainedColsLocal)

cockroach/pkg/sql/opt/memo/statistics_builder.go

Lines 3398 to 3400 in d7e9824

// Calculate histograms.
constrainedCols.ForEach(func(col opt.ColumnID) {
colSet := opt.MakeColSet(col)

cockroach/pkg/sql/opt/colset.go

Lines 82 to 84 in d7e9824

// ForEach calls a function for each column in the set (in increasing order).
func (s ColSet) ForEach(f func(col ColumnID)) { s.set.ForEach(func(i int) { f(retVal(i)) }) }

cockroach/pkg/util/intsets/fast.go

Lines 153 to 155 in d7e9824

i := bits.TrailingZeros64(v)
f(i)
v &^= 1 << uint(i)

cockroach/pkg/sql/opt/colset.go

Lines 82 to 84 in d7e9824

// ForEach calls a function for each column in the set (in increasing order).
func (s ColSet) ForEach(f func(col ColumnID)) { s.set.ForEach(func(i int) { f(retVal(i)) }) }

cockroach/pkg/sql/opt/memo/statistics_builder.go

Lines 3400 to 3402 in d7e9824

colSet := opt.MakeColSet(col)
if sb.updateHistogram(c, colSet, e, s) {
histCols.Add(col)

cockroach/pkg/sql/opt/memo/statistics_builder.go

Lines 3636 to 3638 in d7e9824

if _, _, ok := inputHist.CanFilter(c); ok {
colStat.Histogram = inputHist.Filter(c)
sb.updateDistinctCountFromHistogram(colStat, inputStat.DistinctCount)

cockroach/pkg/sql/opt/props/histogram.go

Lines 406 to 408 in d7e9824

return h.filter(c.Spans.Count(), c.Spans.Get, desc, colOffset, exactPrefix, prefix, c.Columns)
}

cockroach/pkg/sql/opt/props/histogram.go

Lines 340 to 342 in d7e9824

filteredSpan.PreferInclusive(&keyCtx)
filteredBucket = getFilteredBucket(&iter, &keyCtx, &filteredSpan, colOffset)
if !desc && cmpStarts != 0 {

cockroach/pkg/sql/opt/props/histogram.go

Lines 693 to 695 in d7e9824

if !contained {
panic(errors.AssertionFailedf("span must be fully contained in the bucket"))
} 

pkg/sql/conn_executor_exec.go in pkg/sql.(*connExecutor).makeExecPlan at line 2028
pkg/sql/plan_opt.go in pkg/sql.(*planner).makeOptimizerPlan at line 240
pkg/sql/plan_opt.go in pkg/sql.(*optPlanningCtx).buildExecMemo at line 537
pkg/sql/plan_opt.go in pkg/sql.(*optPlanningCtx).reuseMemo at line 507
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).Optimize at line 269
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).optimizeGroup at line 523
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).optimizeGroupMember at line 563
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).enforceProps at line 668
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).optimizeEnforcer at line 717
pkg/sql/opt/xform/optimizer.go in pkg/sql/opt/xform.(*Optimizer).optimizeGroup at line 536
pkg/sql/opt/xform/explorer.go in pkg/sql/opt/xform.(*explorer).exploreGroup at line 185
bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go in pkg/sql/opt/xform.(*explorer).exploreGroupMember at line 24
bazel-out/k8-opt/bin/pkg/sql/opt/xform/explorer.og.go in pkg/sql/opt/xform.(*explorer).exploreSelect at line 259
pkg/sql/opt/xform/select_funcs.go in pkg/sql/opt/xform.(*CustomFuncs).GenerateConstrainedScans at line 441
pkg/sql/opt/xform/scan_index_iter.go in pkg/sql/opt/xform.(*scanIndexIter).ForEach at line 208
pkg/sql/opt/xform/scan_index_iter.go in pkg/sql/opt/xform.(*scanIndexIter).ForEachStartingAfter at line 305
pkg/sql/opt/xform/select_funcs.go in pkg/sql/opt/xform.(*CustomFuncs).GenerateConstrainedScans.func1 at line 505
pkg/sql/opt/xform/index_scan_builder.go in pkg/sql/opt/xform.(*indexScanBuilder).Build at line 249
bazel-out/k8-opt/bin/pkg/sql/opt/norm/factory.og.go in pkg/sql/opt/norm.(*Factory).ConstructScan at line 456
bazel-out/k8-opt/bin/pkg/sql/opt/memo/expr.og.go in pkg/sql/opt/memo.(*Memo).MemoizeScan at line 20146
pkg/sql/opt/memo/logical_props_builder.go in pkg/sql/opt/memo.(*logicalPropsBuilder).buildScanProps at line 186
pkg/sql/opt/memo/statistics_builder.go in pkg/sql/opt/memo.(*statisticsBuilder).buildScan at line 859
pkg/sql/opt/memo/statistics_builder.go in pkg/sql/opt/memo.(*statisticsBuilder).constrainScan at line 948
pkg/sql/opt/memo/statistics_builder.go in pkg/sql/opt/memo.(*statisticsBuilder).applyIndexConstraint at line 3399
pkg/sql/opt/colset.go in pkg/sql/opt.ColSet.ForEach at line 83
pkg/util/intsets/fast.go in pkg/util/intsets.Fast.ForEach at line 154
pkg/sql/opt/colset.go in pkg/sql/opt.ColSet.ForEach.func1 at line 83
pkg/sql/opt/memo/statistics_builder.go in pkg/sql/opt/memo.(*statisticsBuilder).applyIndexConstraint.func1 at line 3401
pkg/sql/opt/memo/statistics_builder.go in pkg/sql/opt/memo.(*statisticsBuilder).updateHistogram at line 3637
pkg/sql/opt/props/histogram.go in pkg/sql/opt/props.(*Histogram).Filter at line 407
pkg/sql/opt/props/histogram.go in pkg/sql/opt/props.(*Histogram).filter at line 341
pkg/sql/opt/props/histogram.go in pkg/sql/opt/props.getFilteredBucket at line 694

Tags

Tag Value
Command server
Environment v23.1.12
Go Version go1.19.13
Platform linux amd64
Distribution CCL
Cockroach Release v23.1.12
Cockroach SHA d7e9824
# of CPUs 16
# of Goroutines 6176

Jira issue: CRDB-38748
@cockroach-sentry cockroach-sentry added O-sentry Originated from an in-the-wild panic report. C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. labels May 14, 2024
This was referenced May 16, 2024
Closed
Closed
Closed
@yuzefovich yuzefovich changed the title Sentry: histogram.go:694: span must be fully contained in the bucket (1) assertion failure Wraps: (2) attached stack trace -- stack trace: | github.com/cockroachdb/cockroach/pkg/sql/opt/props.getF... opt: v23.1.12: span must be fully contained in the bucket May 16, 2024
@yuzefovich yuzefovich added the T-sql-queries SQL Queries Team label May 16, 2024
@yuzefovich
Copy link
Member

dup of https://github.com/cockroachlabs/support/issues/2952

@michae2
Copy link
Collaborator

michae2 commented May 22, 2024

I'm going to re-open this to use it as the public tracking issue.

Here's how to reproduce the problem:

  1. Start a multi-region demo cluster: 
    ./cockroach demo \
--nodes 12 \
--no-example-database \
--insecure \
--multitenant=false \
--demo-locality=\
cloud=aws,region=ap-northeast-2,zone=ap-northeast-2b,pg=ap-northeast-2b1:\
cloud=aws,region=ap-northeast-2,zone=ap-northeast-2a,pg=ap-northeast-2a1:\
cloud=aws,region=ap-northeast-2,zone=ap-northeast-2c,pg=ap-northeast-2c1:\
cloud=aws,region=eu-west-1,zone=eu-west-1b,pg=eu-west-1b1:\
cloud=aws,region=eu-west-1,zone=eu-west-1a,pg=eu-west-1a1:\
cloud=aws,region=us-east-1,zone=us-east-1c,pg=us-east-1c1:\
cloud=aws,region=eu-central-1,zone=eu-central-1b,pg=eu-central-1b1:\
cloud=aws,region=eu-central-1,zone=eu-central-1a,pg=eu-central-1a1:\
cloud=aws,region=eu-central-1,zone=eu-central-1c,pg=eu-central-1c1:\
cloud=aws,region=us-east-1,zone=us-east-1a,pg=us-east-1a1:\
cloud=aws,region=us-east-1,zone=us-east-1b,pg=us-east-1b2:\
cloud=aws,region=eu-west-1,zone=eu-west-1c,pg=eu-west-1c2
  2. Turn off autostats: 
    SET CLUSTER SETTING sql.stats.automatic_collection.enabled = off;
  3. Create this REGIONAL BY ROW table: 
    CREATE DATABASE db PRIMARY REGION "us-east-1" REGIONS = "ap-northeast-2", "eu-west-1", "us-east-1" SURVIVE REGION FAILURE;
USE db;

CREATE TABLE t (
  region crdb_internal_region NOT NULL,
  id UUID NOT NULL DEFAULT gen_random_uuid(),
  a INT NOT NULL,
  PRIMARY KEY (id),
  UNIQUE INDEX (a)
) LOCALITY REGIONAL BY ROW AS region;

INSERT INTO t (region, a) VALUES ('ap-northeast-2', 0), ('eu-west-1', 1), ('us-east-1', 2);

ANALYZE t;
  4. Add another region to the database: 
    ALTER DATABASE db ADD REGION "eu-central-1";
  5. Now this statement will fail with an internal error: 
    INSERT INTO t (region, a) VALUES ('eu-west-1', 3);

@michae2 michae2 reopened this May 22, 2024
@michae2 michae2 self-assigned this May 22, 2024
@michae2
Copy link
Collaborator

michae2 commented May 22, 2024

This is related to #67050.

michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
7ea9d08 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Informs: cockroachdb#124181

Release note: None
michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
7b13432 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sem/tree: check oid and version in tree.(*DEnum).CompareError
0881755 
Make sure when we're comparing two enum datums that they are, in fact,
the same enum type.

Informs: cockroachdb#124181

Release note: None
michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
4e5a5b4 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Informs: cockroachdb#124181

Release note: None
michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
d16e8c4 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue May 23, 2024
@michae2
sem/tree: check oid and version in tree.(*DEnum).CompareError
a329a7d 
Make sure when we're comparing two enum datums that they are, in fact,
the same enum type.

Informs: cockroachdb#124181

Release note: None
@michae2 michae2 mentioned this issue May 23, 2024
Merged
@michae2 michae2 added O-support Would prevent or help troubleshoot a customer escalation - bugs, missing observability/tooling, docs P-1 Issues/test failures with a fix SLA of 1 month labels May 23, 2024
michae2 added a commit to michae2/cockroach that referenced this issue May 25, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
f617a2a 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Informs: cockroachdb#124181

Release note: None
michae2 added a commit to michae2/cockroach that referenced this issue May 25, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
9c527bb 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue May 25, 2024
@michae2
sem/tree: check oid and version in tree.(*DEnum).CompareError
2f42da5 
Make sure when we're comparing two enum datums that they are, in fact,
the same enum type.

Informs: cockroachdb#124181

Release note: None
@michae2 michae2 added branch-release-22.1 Used to mark release blockers and technical advisories for 22.1 branch-release-22.2 Used to mark release blockers and technical advisories for 22.2 branch-release-23.1 Used to mark GA and release blockers and technical advisories for 23.1 branch-release-24.1 Used to mark GA and release blockers and technical advisories for 24.1 branch-release-23.2 Used to mark GA and release blockers and technical advisories for 23.2 labels May 28, 2024
@craig craig bot closed this as completed in ef24bf7 May 29, 2024
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
c745b6b 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Also add this same typecheck to ALTER TABLE INJECT STATISTICS to guard
against injecting histograms that don't match the column type. As part
of this fix I'm removing the testcase added in #46552 which deliberately
injects statistics with a histogram of a different type.

Informs: #124181

Release note: None
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
7bb20bb 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Also add this same typecheck to ALTER TABLE INJECT STATISTICS to guard
against injecting histograms that don't match the column type. As part
of this fix I'm removing the testcase added in #46552 which deliberately
injects statistics with a histogram of a different type.

Informs: #124181

Release note: None
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
f1d8000 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Also add this same typecheck to ALTER TABLE INJECT STATISTICS to guard
against injecting histograms that don't match the column type. As part
of this fix I'm removing the testcase added in #46552 which deliberately
injects statistics with a histogram of a different type.

Informs: #124181

Release note: None
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
a9c8f59 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: #124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sem/tree: check oid and version in tree.(*DEnum).CompareError
0d8219b 
Make sure when we're comparing two enum datums that they are, in fact,
the same enum type.

Informs: #124181

Release note: None
@blathers-crl blathers-crl bot mentioned this issue May 29, 2024
Merged
blathers-crl bot pushed a commit that referenced this issue May 29, 2024
@michae2
sql: add defensive type check to sql.(*optTableStat).init
853a61d 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Also add this same typecheck to ALTER TABLE INJECT STATISTICS to guard
against injecting histograms that don't match the column type. As part
of this fix I'm removing the testcase added in #46552 which deliberately
injects statistics with a histogram of a different type.

Informs: #124181

Release note: None
michae2 added a commit that referenced this issue May 29, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
9718899 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: #124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
nameisbhaskar pushed a commit to nameisbhaskar/cockroach that referenced this issue May 30, 2024
@michae2 @nameisbhaskar
sql: add defensive type check to sql.(*optTableStat).init
8baf3aa 
In statistics builder we assume that the datums decoded from histogram
upper bounds are comparable with datums in spans and constraints. If the
histogram column type were ever different from the table column type,
however, this assumption would not hold.

This should never happen, because histograms are associated with a
column ID, and ALTER TABLE should never re-use a column ID during ALTER
TABLE ADD COLUMN or ALTER TABLE ALTER COLUMN TYPE. But just to be
defensive, add a check to sql.(*optTableStat).init that skips over the
TableStatistic if the histogram column type isn't equivalent to the
table column type.

Also add this same typecheck to ALTER TABLE INJECT STATISTICS to guard
against injecting histograms that don't match the column type. As part
of this fix I'm removing the testcase added in cockroachdb#46552 which deliberately
injects statistics with a histogram of a different type.

Informs: cockroachdb#124181

Release note: None
nameisbhaskar pushed a commit to nameisbhaskar/cockroach that referenced this issue May 30, 2024
@michae2 @nameisbhaskar
sql/stats: evict stats cache entry if user-defined types have changed
95f7d0f 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
nameisbhaskar pushed a commit to nameisbhaskar/cockroach that referenced this issue May 30, 2024
@michae2 @nameisbhaskar
sem/tree: check oid and version in tree.(*DEnum).CompareError
153bf2b 
Make sure when we're comparing two enum datums that they are, in fact,
the same enum type.

Informs: cockroachdb#124181

Release note: None
michae2 added a commit to michae2/cockroach that referenced this issue May 30, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
cdb89ad 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
@michae2 michae2 mentioned this issue May 30, 2024
Merged
michae2 added a commit to michae2/cockroach that referenced this issue May 30, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
2d14052 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
@michae2 michae2 mentioned this issue May 30, 2024
Merged
michae2 added a commit to michae2/cockroach that referenced this issue May 30, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
9eb2302 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
@michae2 michae2 mentioned this issue May 30, 2024
Merged
michae2 added a commit to michae2/cockroach that referenced this issue May 30, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
651e03f 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
@michae2 michae2 mentioned this issue May 30, 2024
Merged
michae2 added a commit to michae2/cockroach that referenced this issue Jun 3, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
43fe2b0 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue Jun 3, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
3222881 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue Jun 3, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
15f2ce0 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit that referenced this issue Jun 3, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
fbb590a 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: #124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue Jun 3, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
8c4ed0e 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue Jun 4, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
9f091dc 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
michae2 added a commit to michae2/cockroach that referenced this issue Jun 5, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
fe9d60c 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: cockroachdb#124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
blathers-crl bot pushed a commit that referenced this issue Jun 11, 2024
@michae2
sql/stats: evict stats cache entry if user-defined types have changed
1c8eef6 
When adding table statistics to the stats cache, we decode histogram
upper bounds into datums. If the histogram column uses a user-defined
type, we hydrate the type and use this to decode.

In statistics builder, these histogram upper bound datums are compared
against datums in spans and constraints. The comparisons assume that the
datums are of equivalent type, but if the user-defined type has changed
sometime after loading the stats cache entry, this might not be true.

If the user-defined type has changed, we need to evict and re-load the
stats cache entry so that we decode histogram datums with a freshly-
hydrated type.

(We were already checking UDT versions when building the optTable in
sql.(*optCatalog).dataSourceForTable, but the newly-built optTable used
the existing table statistics instead of refreshing those, too.)

Fixes: #124181

Release note (bug fix): Fix a bug where a change to a user-defined type
could cause queries against tables using that type to fail with an error
message like:

  "histogram.go:694: span must be fully contained in the bucket"

The change to the user-defined type could come directly from an ALTER
TYPE statement, or indirectly from an ALTER DATABASE ADD REGION or DROP
REGION statement (which implicitly change the crdb_internal_region
type).

This bug has existed since UDTs were introduced in v20.2.
@blathers-crl blathers-crl bot mentioned this issue Jun 11, 2024
Merged
@yuzefovich yuzefovich mentioned this issue Jul 8, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@michae2 michae2

Labels
branch-release-20.2 Used to mark technical advisories for 20.2 branch-release-21.1 Used to mark technical advisories for 21.1 branch-release-21.2 Used to mark technical advisories for 21.2 branch-release-22.1 Used to mark release blockers and technical advisories for 22.1 branch-release-22.2 Used to mark release blockers and technical advisories for 22.2 branch-release-23.1 Used to mark GA and release blockers and technical advisories for 23.1 branch-release-23.2 Used to mark GA and release blockers and technical advisories for 23.2 branch-release-24.1 Used to mark GA and release blockers and technical advisories for 24.1 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. O-support Would prevent or help troubleshoot a customer escalation - bugs, missing observability/tooling, docs P-1 Issues/test failures with a fix SLA of 1 month T-sql-queries SQL Queries Team
Projects
SQL Queries
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

sql/stats: evict stats cache entry if user-defined types have changed michae2/cockroach
3 participants
@yuzefovich @michae2 @cockroach-sentry