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

sql/stats: evict stats cache entry if user-defined types have changed #124603

Merged
merged 3 commits into from
May 29, 2024
Merged

sql/stats: evict stats cache entry if user-defined types have changed #124603

merged 3 commits into from
May 29, 2024
+334 −50

Commits on May 29, 2024

  1. sql: add defensive type check to sql.(*optTableStat).init 

    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
    @michae2
    michae2 committed May 29, 2024
    Configuration menu
    Copy the full SHA
    72f97c8 View commit details
    Browse the repository at this point in the history

  2. sql/stats: evict stats cache entry if user-defined types have changed 

    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 committed May 29, 2024
    Configuration menu
    Copy the full SHA
    ef24bf7 View commit details
    Browse the repository at this point in the history

  3. sem/tree: check oid and version in tree.(*DEnum).CompareError 

    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 committed May 29, 2024
    Configuration menu
    Copy the full SHA
    b6aa169 View commit details
    Browse the repository at this point in the history