23.1 GA Release Notes #16951
23.1 GA Release Notes #16951
Conversation
Files changed:
|
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify site settings. |
✅ Netlify Preview
To edit notification comments on pull requests, go to your Netlify site settings. |
|
@mikeCRL I think it's just to make sure there are no references directly to I also went through and tweaked some of the includes/Liquid to get the docs to build and pass htmltest. Sending a commit for this soon. |
nickvigilante
force-pushed
the
23.1-GA-RNs
branch
from
681f7b0 to
8d2f95d
Compare
|
@nickvigilante While I updated the tables to use |
nickvigilante
force-pushed
the
23.1-GA-RNs
branch
from
8d2f95d to
eda0bfa
Compare
|
@mikeCRL The fact that the body rows have a larger font than the header rows is weird to me. Is there any reason why the body rows have to have a larger font size? Take a look at the v22.2.0 RN table. |
_includes/releases/v23.1/v23.1.0.md
Outdated
|
|
||
| - Replaced the `cdc_prev()` [function](../v23.1/functions-and-operators.html) in favor of a `cdc_prev` tuple. This is an incompatible change that may break [changefeeds](../v23.1/change-data-capture-overview.html) that use the previous `cdc_prev()` function. [#85177][#85177] | ||
| - [`SHOW RANGES FOR TABLE`](../v23.1/show-ranges.html) 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. [#93545][#93545] | ||
| - CockroachDB now supports sharing storage ranges across multiple indexes/tables. As a result, there is no longer a guarantee that there is at most one SQL object (e.g., table/index/sequence/materialized view) per storage range. Therefore, the columns `table_id`, `database_name`, `schema_name`, `table_name` and `index_name` in `crdb_internal.ranges` and `.ranges_no_leases` have become nonsensical: a range cannot be attributed to a single table/index anymore. As a result: |
There was a problem hiding this comment.
This bullet point and the points below need to clarify the relationship with the new cluster setting wrt the deprecated behavior.
NB: even though the default behavior is compatible with v22.2, I still would like this to be mentioned in the backward-incompatible changes, to stimulate customers to adapt their automation
There was a problem hiding this comment.
This bullet point and the points below need to clarify the relationship with the new cluster setting wrt the deprecated behavior.
I've updated this so that it says
... cannot be attributed to a single table/index anymore. For the v23.1 release, the default behavior of
SHOW RANGESis retained, but users should consider setting the cluster settingsql.show_ranges_deprecated_behavior.enabledtofalse. This will have the following effects that will become the defaults in a future release:
_includes/releases/v23.1/v23.1.0.md
Outdated
| - 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] |
There was a problem hiding this comment.
i believe this is also subject to the new cluster setting
There was a problem hiding this comment.
I've updated this to say
When the cluster setting
sql.show_ranges_deprecated_behavior.enabledis set tofalse(recommended in v23.1), ...
_includes/releases/v23.1/v23.1.0.md
Outdated
| - 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`](../v23.1/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] |
There was a problem hiding this comment.
i believe this is also subject to the new cluster setting
There was a problem hiding this comment.
Similar to the other change, I've prepended the clause
When the cluster setting
sql.show_ranges_deprecated_behavior.enabledis set tofalse(recommended in v23.1), ...
| - 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] |
There was a problem hiding this comment.
NB: this one is not subject to the new cluster setting
There was a problem hiding this comment.
I've reordered this so it appears after the things that are subject to the new cluster setting
@nickvigilante I don't have a strong feeling about the header row size, so I used the default, though I do also think that if the header text matched the bolded first column entries, that might also be odd. I find the small table text (e.g. on 22.2) hard to read at default zoom, and also especially without consistent links this time for the left column, there's otherwise nothing to differentiate those summaries; I find the bold text sets it apart and makes it easier to skim, and avoids this table appearing even more dense/text heavy. @shannonbradshaw Would you like to help settle a style question that has arisen, by comparing the current 23.1 tables to the 22.2 tables, which use our default style? I happened upon different styles here (which I like) because I ended up needing to transform my WIP tables to HTML instead of Markdown. |
|
@mikeCRL do you have a specific question on this? I don't want to infer what you're asking. |
|
FWIW, I'm not a fan of the bolded feature name in the table. I also think the cluster setting font size is too small. That said, the font size seems to be the same as previous releases. |
|
@mikeCRL Makes sense. We can add an action item for after the release to make styling adjustments to the table CSS. |
|
@shannonbradshaw Sorry, just trying to decide whether to keep both workarounds on size and boldness, or switch to the default in the prior RNs for now. And I appreciate your feedback. @nickvigilante any objection to dropping the boldness but keeping the size for this one? |
|
@mikeCRL No objections with that. |
|
For others on the PR, this is the exchange that prompted knz's comments above. |
|
Thank you @knz. @rmloveland would you mind reviewing Raphael's comments and making/suggesting any edits to the Backward-Incompatible Changes section bullets on |
_includes/releases/v23.1/v23.1.0.md
Outdated
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td><p>Add parquet format to changefeeds </p> |
There was a problem hiding this comment.
Parquet format for changefeeds needs to be removed, we don't want this to be public yet.
There was a problem hiding this comment.
There's a known limitation I added for Parquet (https://github.com/cockroachdb/docs/pull/16902/files) - should I remove?
| <tr> | ||
| <td><p>Enforce supported backup versions</p> | ||
| </td> | ||
| <td><p>To help ensure backups and restores are successful, CockroachDB now enforces its previous support for restoring backups from up to two minor versions prior. Previously, restoring backups produced from even earlier versions was possible, but unreliable. Now, this operation is prevented with an error. |
There was a problem hiding this comment.
| <td><p>To help ensure backups and restores are successful, CockroachDB now enforces its previous support for restoring backups from up to two minor versions prior. Previously, restoring backups produced from even earlier versions was possible, but unreliable. Now, this operation is prevented with an error. | |
| <td><p>To help ensure backups and restores are successful, CockroachDB now enforces its previous [support for restoring backups](restoring-backups-across-versions.html) from up to two minor versions prior. Previously, restoring backups produced from even earlier versions was possible, but unreliable. Now, this operation is prevented with an error. |
Co-authored-by: Kathryn Hancox <[email protected]>
Co-authored-by: Kathryn Hancox <[email protected]>
Co-authored-by: Kathryn Hancox <[email protected]>
Remove broken link until after GA release
To Do:
v23.1path.<strong>to<p>versions.csvdate for 23.1 from2023-05-10(required for site preview to work) to2023-05-15prior to merging.Post-release follow-up: