From 61c4306eb8a1c2318da759fa5d8d373b1701acac Mon Sep 17 00:00:00 2001 From: andf-crl <101147019+andf-crl@users.noreply.github.com> Date: Tue, 14 Feb 2023 11:20:29 -0500 Subject: [PATCH] Update v23.1.0-alpha.2.md --- _includes/releases/v23.1/v23.1.0-alpha.2.md | 25 +++++++++------------ 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/_includes/releases/v23.1/v23.1.0-alpha.2.md b/_includes/releases/v23.1/v23.1.0-alpha.2.md index 736fc1a7d2b..b303407c300 100644 --- a/_includes/releases/v23.1/v23.1.0-alpha.2.md +++ b/_includes/releases/v23.1/v23.1.0-alpha.2.md @@ -11,20 +11,15 @@ Release Date: February 13, 2022 - The aforementioned columns in the `crdb_internal` virtual tables have been removed. Existing code can use the [`SHOW RANGES`](../v22.2/show-ranges.html) statement instead, optionally using `WITH KEYS` to expose the raw start/end keys. - `SHOW RANGES FROM DATABASE` continues to report one row per range, but stops returning the database / schema / table / index name. - `SHOW RANGES FROM TABLE` continues to report one row per range, but stops returning the index name. Suggested replacements: - - Instead of: `SELECT range_id FROM crdb_internal.ranges WHERE table_name = 'x'` - Use: `SELECT range_id FROM [SHOW RANGES FROM TABLE x]` - - Instead of `SELECT range_id FROM crdb_internal.ranges WHERE table_name = $1 OR table_id = $2` (variable / unpredictable table name or ID) - Use: `SELECT range_id FROM [SHOW RANGES FROM CURRENT_CATALOG WITH TABLES] WHERE table_name = $1 OR table_id = $2` - - Instead of `SELECT start_key FROM crdb_internal.ranges WHERE table_name = 'x'` - Use: `SELECT raw_start_key FROM [SHOW RANGES FROM TABLE x WITH KEYS]` - - Instead of `SELECT start_key FROM crdb_internal.ranges WHERE table_name = $1 OR table_id = $2` (unpredictable / variable table name or ID) - Use: `SELECT raw_start_key FROM [SHOW RANGES FROM CURRENT_CATALOG WITH TABLES, KEYS] WHERE table_name = $1 OR table_id = $2` [#93644][#93644] + - Instead of: `SELECT range_id FROM crdb_internal.ranges WHERE table_name = 'x'`, use: `SELECT range_id FROM [SHOW RANGES FROM TABLE x]` + - Instead of `SELECT range_id FROM crdb_internal.ranges WHERE table_name = $1 OR table_id = $2` (variable / unpredictable table name or ID), use: `SELECT range_id FROM [SHOW RANGES FROM CURRENT_CATALOG WITH TABLES] WHERE table_name = $1 OR table_id = $2` + - Instead of `SELECT start_key FROM crdb_internal.ranges WHERE table_name = 'x'`, use: `SELECT raw_start_key FROM [SHOW RANGES FROM TABLE x WITH KEYS]` + - Instead of `SELECT start_key FROM crdb_internal.ranges WHERE table_name = $1 OR table_id = $2` (unpredictable / variable table name or ID), use: `SELECT raw_start_key FROM [SHOW RANGES FROM CURRENT_CATALOG WITH TABLES, KEYS] WHERE table_name = $1 OR table_id = $2` [#93644][#93644] - The format of the columns `start_key` and `end_key` for `SHOW RANGES FROM DATABASE` and `SHOW RANGES FROM TABLE` have been extended to include which table/index the key belongs to. This is necessary because a range can now contain data from more than one table/index. [#93644][#93644] - The format of the columns `start_key` and `end_key` for `SHOW RANGE ... FOR ROW` has been changed to be consistent with the output of `SHOW RANGES FROM INDEX`. [#93644][#93644] - The output of [`SHOW RANGES`](../v22.2/show-ranges.html) no longer includes `range_size`, `range_size_mb`, `lease_holder`, or `lease_holder_localities` by default. This ensures that `SHOW RANGES` remains fast in the common case. Use the new option `WITH DETAILS` to include these columns. [#93644][#93644] - If a SQL database is created with a name that starts with `cluster:...` (e.g., `CREATE DATABASE "cluster:foo"`, clients will no longer be able to connect to it directly via a pre-existing URL connection string. The URL will need to be modified in this case. For example: - - Previously: `postgres://servername/cluster:foo` - Now: `postgres://servername/cluster:foo&options=-ccluster=system` + - Previously: `postgres://servername/cluster:foo`; now: `postgres://servername/cluster:foo&options=-ccluster=system` - This syntax selects the tenant named `system` and then the database named `cluster:foo` inside it. When the `-ccluster:system` option is not specified, `cluster:foo` in the database name position is interpreted as a request to connect to a tenant named `foo`, which likely does not exist. Connections to databases whose name does not start with `cluster:` (the most common case) are not affected by this change. [#92580][#92580] - Changefeeds using "preview" expressions (released in v22.2.0) and that access the previous state of the row using the `cdc_prev()` function will no longer work and will need to be recreated with new syntax. [#94429][#94429] @@ -92,7 +87,7 @@ We chose a default of `25h` originally to accommodate daily incremental backups - Previously, CockroachDB would crash if a user creates a [user-defined function (UDF)](../v22.2/user-defined-functions.html) whose function signature includes a implicit record type (essentially a table) which has a column using a user defined enum type. The root cause was a hydration deadloop when looking up descriptors during hydration. This fix adds a new flag to avoid hydration in order to avoid the deadloop. [#94106][#94106] - Previously, error messages for missing users sometimes had different forms. This is now unified in the form `role/user "user" does not exist`. [#94677][#94677] - Added cluster settings to control tenant capabilities relying on KV admin functions. [#94314][#94314] -- [User-defined functions (UDF)](../v22.2/user-defined-functions.html) with subqueries in the body of the function are now supported. [#94962][#94962] +- [User-defined functions (UDFs)](../v22.2/user-defined-functions.html) with subqueries in the body of the function are now supported. [#94962][#94962] - Previously, setting a table's locality was not allowed if the table contained any hash sharded index. This restriction is now removed. [#94436][#94436] - Users can now add a super region when creating a database. [#93939][#93939] - [`COPY`](../v22.2/copy-from.html) now logs an error during the insert phase on the `SQL_EXEC` logging channel. [#95038][#95038] @@ -112,12 +107,12 @@ We chose a default of `25h` originally to accommodate daily incremental backups - Previously, [`SHOW BACKUP`](../v22.2/show-backup.html) options would get parsed as `kv_options`, which meant that a user could not pass multiple values to a `SHOW BACKUP` option, causing feature gaps in `SHOW BACKUP` relative to [`BACKUP`](../v22.2/backup.html) and [`RESTORE`](../v22.2/restore.html). This patch rewrites the show backup option parser, closing the following feature gaps: - A user can now pass and check multiple KMS URIs in `SHOW BACKUP` - A user can pass locality-aware `incremental_locations`, allowing a user to also pass the `check_files` parameter to a locality-aware backup chain that also specifies the backup incremental location. [#95562][#95562] -- Update the name of the `cpuNanos` column to `cpuSQLNanos` on `crdb_internal.statement_statistics` and `system.statement_statistics` [#96278][#96278] +- Updated the name of the `cpuNanos` column to `cpuSQLNanos` on `crdb_internal.statement_statistics` and `system.statement_statistics` [#96278][#96278] - Some queries with `EXISTS` subqueries which previously resulted in the error "could not decorrelate subquery" now succeed. [#95883][#95883] - Users can query the `crdb_internal.kv_dropped_relation` table to see which tables, materialized views and sequences are currently already dropped but have not yet been garbage collected, along with the garbage collection TTL setting that is currently in force. This setting originates from the table's own zone configuration, or from its parent database which it inherits, or in turn from the default zone configuration. These settings are typically set using `ALTER TABLE ... CONFIGURE ZONE USING gc.ttlseconds = ...;`. [#96217][#96217] - Administrators may now call a new [built-in function](../v22.2/functions-and-operators.html) `crdb_internal.upsert_dropped_relation_gc_ttl` to retroactively set the garbage collection TTL on a table, materialized view, or sequence which has already been dropped. Effectively, this retroactively performs `ALTER TABLE ... CONFIGURE ZONE USING gc.ttlseconds = ...;`. Note that this statement is prevented from being executed on dropped tables because they can no longer be referenced by name at that point. Usage of this built-in is typically in conjunction with the recently-added `crdb_internal.kv_dropped_relations` virtual table. For example, garbage collection can be triggered ASAP for all dropped relations by querying: `SELECT crdb_internal.upsert_dropped_relation_gc_ttl(id, '1 second') FROM crdb_internal.kv_dropped_relations;`. Doing so for all tables in a dropped database requires filtering on the `parent_id` column, the database name being lost at that point. [#96217][#96217] -- Allow `*` expressions in [user-defined functions (UDF)](../v22.2/user-defined-functions.html). [#95710][#95710] -- Previously, [user-defined functions (UDF)](../v22.2/user-defined-functions.html) could be created with any volatility no matter if the function body statements contained any expression which would violate the target volatility. For example, an immutable function might use `random()` in it. This change added validations to guarantee that all statements in the function body should be as strict as the expected UDF volatility. [#96476][#96476] +- Allow `*` expressions in [user-defined functions (UDFs)](../v22.2/user-defined-functions.html). [#95710][#95710] +- Previously, [user-defined functions (UDFs)](../v22.2/user-defined-functions.html) could be created with any volatility no matter if the function body statements contained any expression which would violate the target volatility. For example, an immutable function might use `random()` in it. This change added validations to guarantee that all statements in the function body should be as strict as the expected UDF volatility. [#96476][#96476]

Operational changes

@@ -250,7 +245,7 @@ We chose a default of `25h` originally to accommodate daily incremental backups - Significantly reduced CPU usage of the underlying gossip network in large clusters. [#89613][#89613] - Refactored the query logic when fetching database index recommendations for the `DatabaseDetails` API endpoint, greatly reducing the query time and cost, particularly for large schemas. [#93937][#93937] - Improved performance when populating `crdb_internal.default_privileges`. [#94247][#94247] -- Some types of [user-defined functions (UDF)](../v22.2/user-defined-functions.html) are now inlined in query plans as relation expressions, which speeds up their evaluation. UDFs must be non-volatile and have a single statement in the function body to be inlined. [#92955][#92955] +- Some types of [user-defined functions (UDFs)](../v22.2/user-defined-functions.html) are now inlined in query plans as relation expressions, which speeds up their evaluation. UDFs must be non-volatile and have a single statement in the function body to be inlined. [#92955][#92955] - Improved the performance of `pg_{function,table,type}_is_visible`. [#94339][#94339] - Long chains of incremental backups and restore of such chains will now allocate less memory during the unmarshaling of metadata. [#93997][#93997] - Extended the RPC compression encoding with a length prefixing format, allowing more efficient decompression on receivers. [#93871][#93871]