You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
151362: sql: gate system database behind session variable r=angles-n-daemons a=angles-n-daemons
It today isn't quite clear which internal objects are safe for external usage. For example, selecting from crdb_internal.zones is considered safe, while deleting from system.jobs is not.
To address this, we're adding a gate protecting some of these internals, as well as auditing around their usage so that we can better see how the internal state of the database may have been modified.
The start of this effort is this PR, which adds an gate on the privilege check for system descriptors. This gate is simple now, it checks whether the caller is internal or if the override session variable is set to access "unsafe internals".
It should be noted that allowance is the default to start, so that extensive testing can be done on this feature before its rolled out more widely.
Fixes: #149594Fixes: #151333
Epic: CRDB-24527
Release note (sql change): Adds a new session variable `allow_unsafe_internals` and corresponding cluster setting (`sql.defaults.allow_unsafe_internals`) which controls access to the `system` database.
151774: kv,sql: explicitly set IsReverse on the Header r=yuzefovich a=yuzefovich
When processing batches that touch multiple ranges, the DistSender needs
to know whether to iterate across those ranges in the forward or reverse
manner (i.e. ASC or DESC for range keys). Currently, it only uses the
reverse direction if it finds at least one ReverseScan request in the
batch, and it uses the forward direction otherwise. This goes against
the needs of SQL which might issue point Gets when performing a SQL
revscan operation, and currently in such a scenario we would hit an
error (instead of returning the results in incorrect order).
This commit fixes the issue by introducing `IsReverse` boolean on the
batch header to explicitly indicate the direction for range iteration.
It seems reasonable that the caller should be explicit about this, and
we also add a validation that the boolean is set correctly (meaning that
it should be `false` when only forward range requests are present and
`true` when only reverse range requests are present).
In order to simplify the story a bit, the DistSender will no longer
allow batches that have both forward and reverse range requests.
Previously, this limitation only applied to the batches with limits, but
now it's extended to be unconditional. SQL never issues such batches, so
the limitation seems acceptable. This limitation required some updates
to the existing tests, including KVNemesis to not generate batches that
are now disallowed.
See also 619f395 for some related context.
Given that the new header field is only examined on the KV client, the
change can be backported with no mixed-version concerns.
Fixes: #146637.
Release note (bug fix): Previously, CockroachDB could hit an error
`ERROR: span with results after resume span...` when evaluating some
queries with ORDER BY ... DESC in an edge case. The bug has been present
since about v22.1 and is now fixed.
151949: sql: prep migration for sampled_query and sampled_transaction events r=kyle-a-wong a=kyle-a-wong
In v26.1, sampled_query and sampled_transaction events will be moved
from the TELEMETRY logging channel to the SQL_EXEC logging channel.
This commit gates this migration under the cluster setting:
`log.channel_compatibility_mode.enabled` and will log these events
to the SQL_EXEC channel if this setting is set to false. Users can
set this setting to false in their clusters to validate, test, and
identify potential downstream impacts to their logging setups and
pipelines.
Epic: [CRDB-53410](https://cockroachlabs.atlassian.net/browse/CRDB-53410)
Part of: [CRDB-53412](https://cockroachlabs.atlassian.net/browse/CRDB-53412)
Release note (ops change): sampled_query and sampled_transaction
events will be moved to the SQL_EXEC channel in 26.1. In order to
test the impact of these changes, users can set the setting:
`log.channel_compatibility_mode.enabled` to false. Note that this
will cause these logs to start logging in the SQL_EXEC channel so
this shouldn't be tested in a production environment.
----
This is a stacked PR, only the last commit in this PR should be reviewed
Co-authored-by: Brian Dillmann <brian.dillmann@cockroachlabs.com>
Co-authored-by: Yahor Yuzefovich <yahor@cockroachlabs.com>
Co-authored-by: Kyle Wong <37189875+kyle-a-wong@users.noreply.github.com>
0 commit comments