sql: TRUNCATE unable to preserve split point when run from a tenant #82944
Assignees
Labels
A-multitenancy
Related to multi-tenancy
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
T-sql-foundations
SQL Foundations Team (formerly SQL Schema + SQL Sessions)
Comments
knz
added
C-bug
ecwall
added
the
T-sql-foundations
craig bot
pushed a commit
that referenced
this issue
Dec 14, 2022
93153: rttanalysis: don't count leasing the database desc r=andreimatei a=andreimatei A bunch of rtt-analysis tests were counting a request for leasing the database descriptor. This is not interesting. This patch makes the test framework lease it first through a "USE" statement. The number of KV requests required for leasing is currently mis-counted. We count 1, but in reality it's 4. A different patch will correct the miscounting that, at which point that would be too significant for the tests. Release note: None Epic: None 93325: multitenant: retain range splits after TRUNCATE for secondary tenants r=knz a=ecwall Fixes #69499 Fixes #82944 Existing split points are preserved after a TRUNCATE statement is executed by a secondary tenant. Release note: None 93354: tracing: disallow children of sterile span with different Tracer r=andreimatei a=andreimatei Before this patch, creating a "child" of a sterile span with a different Tracer than the one used to create the sterile span was tolerated - on the argument that sterile spans don't actually get children (the would-be child span is created as a root), so the arguments for not allowing a children to be created with different tracers don't apply. At the same time, creating a child of a noop span with a different Tracer than the noop span's Tracer was documented to not be allowed. In practice, it was, because the code was confused [1]. This patch disallows creating children of sterile spans with a different tracer, for consistency with all the other spans. The patch also makes it a panic for the children of noop spans to be created with a different Tracer. This is all meant as a cleanup / code simplification. [1] WithParent(sp) meant to treat sterile spans differently than noop spans but it was using sp.IsSterile(), which returns true for both. As such, it was unintentionally returning an empty parent option. startSpanGeneric() meant to check the tracer of parent noop spans, but it was failing to actually do so because it was going through the opts.Parent.empty(). Release note: None Epic: None 93545: sql: make SHOW RANGES FOR TABLE include all indexes r=ajwerner a=knz Informs #80906. Fixes #93546. Fixes #82995. Release note (backward-incompatible change): `SHOW RANGES FOR TABLE` now includes rows for all indexes that support the table. Prior to this change, `SHOW RANGES FOR TABLE foo` was an alias for `SHOW RANGES FOR INDEX foo@primary`. This was causing confusion, as it would miss data for secondary indexes. It is still possible to filter to just the primary index using `SHOW RANGES FOR INDEX foo@primary`. The statement output now also includes the index name. 93557: syntheticprivilegecache: scan all privileges at startup r=ajwerner a=ajwerner #### syntheticprivilegecache: move caching logic out of sql This is a pure refactor to move the logic for caching synthetic privileges from the sql package. This will make it easier to add features later. #### syntheticprivilegecache: scan all privileges at startup Fixes #93182 This commit attempts to alleviate the pain caused by synthetic virtual table privileges introduced in 22.2. We need to fetch privileges for virtual tables to determine whether the user has access. This is done lazily. However, when a user attempts to read a virtual table like pg_class or run SHOW TABLES it will force the privileges to be determined for each virtual table (of which there are 290 at the time of writing). This sequential process can be somewhat slow in a single region cluster and will be very slow in an MR cluster. This patch attempts to somewhat alleviate this pain by scanning the table eagerly during server startup. Release note (performance improvement): In 22.2 we introduced privileges on virtual tables (system catalogs like pg_catalog, information_schema, and crdb_internal). A problem with this new feature is that we now must fetch those privileges into a cache before we can use those tables or determine their visibility in other system catalogs. This process used to occur on-demand, when the privilege was needed. Now we'll fetch these privileges eagerly during startup to mitigate the latency when accessing pg_catalog right after the server boots up. 93563: pgwire: handle decoding Geometry/Geography in binary r=rafiss a=otan Resolves #81066 Resolves #93352 Release note (bug fix): Previously, CockroachDB would error when receiving Geometry/Geography using binary parameters. This is now resolved. 93618: cli,cliccl: move some mt commands to cliccl r=ajwerner a=ajwerner Part of #91714 Epic: none Release note: None Co-authored-by: Andrei Matei <[email protected]> Co-authored-by: Andrei Matei <[email protected]> Co-authored-by: Evan Wall <[email protected]> Co-authored-by: Raphael 'kena' Poss <[email protected]> Co-authored-by: Andrew Werner <[email protected]> Co-authored-by: Oliver Tan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the problem
Internally TRUNCATE works by dropping all indexes from the table then creating new indexes with new IDs.
If the user had run SPLIT before on the table, TRUNCATE contains code to extract the split points pre-DROP, then apply them again post-CREATE.
All this code is currently disabled under multitenancy.
This is a problem as we want to continue to preserve split point in CC Dedicated with multi-tenancy enabled.
Expected behavior
The TRUNCATE code unconditionally runs a KV request through the KV connector to "extract the split points" from an existing table (key range) pre-DROP, then sends another request to "apply the split points" post-CREATE.
This code runs regardless of the privilege level of the tenant. In non-privileged tenants, the "extract" operation would return the empty set so there is nothing to apply.
Jira issue: CRDB-16747
Epic CRDB-16746
The text was updated successfully, but these errors were encountered: