Merge branch 'main' into feat/netlify-block

src/current/_data/releases.yml

@@ -6390,10 +6390,30 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v23.1.23
-  cloud_only: true
-  cloud_only_message_short: 'Available only for select CockroachDB Cloud clusters'
-  cloud_only_message: >
-      This version is currently available only for select
-      CockroachDB Cloud clusters. To request to upgrade
-      a CockroachDB self-hosted cluster to this version,
-      [contact support](https://support.cockroachlabs.com/hc/requests/new)
+
+- release_name: v24.2.0-beta.2
+  major_version: v24.2
+  release_date: '2024-07-24'
+  release_type: Testing
+  go_version: go1.22.5
+  sha: 60d3fb84a73f5e31c99404223f3a0ba91e67f489
+  has_sql_only: true
+  has_sha256sum: true
+  mac:
+    mac_arm: true
+    mac_arm_experimental: true
+    mac_arm_limited_access: false
+  windows: true
+  linux:
+    linux_arm: true
+    linux_arm_experimental: false
+    linux_arm_limited_access: false
+    linux_intel_fips: true
+    linux_arm_fips: false
+  docker:
+    docker_image: cockroachdb/cockroach-unstable
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v24.2.0-beta.1

src/current/_includes/releases/v24.2/v24.2.0-beta.2.md

@@ -0,0 +1,50 @@
+## v24.2.0-beta.2
+
+Release Date: July 24, 2024
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v24-2-0-beta-2-security-updates">Security updates</h3>
+
+- URLs in the following SQL statements are now sanitized of any secrets before being written to [unredacted logs]({% link v24.2/configure-logs.md %}#redact-logs). [#127360][#127360]
+- [`ALTER BACKUP SCHEDULE`]({% link v24.2/alter-backup.md %})
+- [`ALTER BACKUP`]({% link v24.2/alter-backup.md %})
+- [`ALTER CHANGEFEED SET sink`]({% link v24.2/alter-changefeed.md %})
+- [`BACKUP`]({% link v24.2/backup.md %})
+- [`COPY`]({% link v24.2/copy-from.md %})
+- [`CREATE CHANGEFEED`]({% link v24.2/create-changefeed.md %})
+- [`CREATE EXTERNAL CONNECTION`]({% link v24.2/create-external-connection.md %})
+- [`CREATE SCHEDULE FOR BACKUP`]({% link v24.2/create-schedule-for-backup.md %})
+- [`CREATE SCHEDULE FOR CHANGEFEED`]({% link v24.2/create-schedule-for-changefeed.md %})
+- [`EXPORT`]({% link v24.2/export.md %})
+- [`IMPORT INTO`]({% link v24.2/import-into.md %})
+- [`RESTORE`]({% link v24.2/restore.md %})
+- [`SHOW BACKUPS`]({% link v24.2/show-backup.md %})
+- [`SHOW BACKUP`]({% link v24.2/show-backup.md %})
+
+<h3 id="v24-2-0-beta-2-sql-language-changes">SQL language changes</h3>
+
+- The new [cluster setting]({% link v24.2/cluster-settings.md %}) [`sql.auth.grant_option_for_owner.enabled`]({% link v24.2/cluster-settings.md %}#setting-sql-auth-grant-option-for-owner-enabled) controls whether the owner of an object has permission to grant permission on the object to other [users]({% link v24.2/security-reference/authorization.md %}#roles). When set to `true` (the default), the [`GRANT OPTION`]({% link v24.2/show-grants.md %}#privilege-grants) is is implicitly granted to the object owner, who can grant permissions on the object to other users, preserving the existing behavior of CockroachDB. When set to `false`, the `GRANT OPTION` is not implicitly given to the owner of an object. The owner's permissions do not change, but they can no longer grant permissions to others unless the `GRANT OPTION` is granted to them explicitly.  [#126960][#126960]
+- Fixed a bug in which the `DISCARD` statement was disallowed when the [session setting]({% link v24.2/session-variables.md %}#default-transaction-read-only) `default_transaction_read_only = on`. [cockroachdb/cockroach#127364][#127364]
+
+<h3 id="v24-2-0-beta-2-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug that could cause [`CREATE INVERTED INDEX`]({% link v24.2/create-index.md %}#create-gin-indexes) and [`ALTER TABLE ... SET LOCALITY REGIONAL BY ROW`]({% link v24.2/alter-table.md %}#set-the-table-locality-to-regional-by-row) statements to fail if the corresponding table contained columns with non-standard characters in their names, such as tabs or newlines. This bug was introduced along with [inverted indexes]({% link v24.2/inverted-indexes.md %}) in v2.0. [#126996][#126996]
+- Fixed a bug introduced in v23.2 that could cause a [gateway node]({% link v24.2/architecture/life-of-a-distributed-transaction.md %}#gateway) to crash while executing an [`INSERT`]({% link v24.2/insert.md %}) statement in a [`REGIONAL BY ROW`]({% link v24.2/alter-table.md %}#set-the-table-locality-to-regional-by-row) table. [#127278][#127278]
+- Fixed a bug where a [schema change]({% link v24.2/online-schema-changes.md %}) could hang if the [lease]({% link v24.2/architecture/replication-layer.md %}#leases) [rangefeed]({% link v24.2/create-and-configure-changefeeds.md %}#enable-rangefeeds) stopped receiving updates. [#127488][#127488]
+
+<div class="release-note-contributors" markdown="1">
+
+<h3 id="v24-2-0-beta-2-contributors">Contributors</h3>
+
+This release includes 45 merged PRs by 18 authors.
+
+</div>
+
+[#126960]: https://github.com/cockroachdb/cockroach/pull/126960
+[#126996]: https://github.com/cockroachdb/cockroach/pull/126996
+[#127278]: https://github.com/cockroachdb/cockroach/pull/127278
+[#127360]: https://github.com/cockroachdb/cockroach/pull/127360
+[#127364]: https://github.com/cockroachdb/cockroach/pull/127364
+[#127392]: https://github.com/cockroachdb/cockroach/pull/127392
+[#127488]: https://github.com/cockroachdb/cockroach/pull/127488

src/current/_includes/v23.1/backups/serverless-locality-aware.md

@@ -1 +1 @@
-CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link v23.1/data-domiciling.md %}) requirements.
+CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with {% if page.title contains "Cloud" or page.title contains "Serverless" %} [data domiciling]({% link {{site.current_cloud_version}}/data-domiciling.md %}) {% else %} [data domiciling]({% link {{page.version.version}}/data-domiciling.md %}) {% endif %} requirements.

src/current/_includes/v23.2/backups/serverless-locality-aware.md

@@ -1 +1 @@
-CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link v23.2/data-domiciling.md %}) requirements.
+CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with {% if page.title contains "Cloud" or page.title contains "Serverless" %} [data domiciling]({% link {{site.current_cloud_version}}/data-domiciling.md %}) {% else %} [data domiciling]({% link {{page.version.version}}/data-domiciling.md %}) {% endif %} requirements.

src/current/_includes/v24.1/backups/serverless-locality-aware.md

@@ -1 +1 @@
-CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link v23.2/data-domiciling.md %}) requirements.
+CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with {% if page.title contains "Cloud" or page.title contains "Serverless" %} [data domiciling]({% link {{site.current_cloud_version}}/data-domiciling.md %}) {% else %} [data domiciling]({% link {{page.version.version}}/data-domiciling.md %}) {% endif %} requirements.

src/current/_includes/v24.2/backups/serverless-locality-aware.md

@@ -1 +1 @@
-CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with [data domiciling]({% link v23.2/data-domiciling.md %}) requirements.
+CockroachDB {{ site.data.products.serverless }} clusters operate with a [different architecture]({% link cockroachcloud/architecture.md %}#cockroachdb-serverless) compared to CockroachDB {{ site.data.products.core }} and CockroachDB {{ site.data.products.dedicated }} clusters. These architectural differences have implications for how locality-aware backups can run. Serverless clusters will scale resources depending on whether they are actively in use, which means that it is less likely to have a SQL pod available in every locality. As a result, your Serverless cluster may not have a SQL pod in the locality where the data resides, which can lead to the cluster uploading that data to a storage bucket in a locality where you do have active SQL pods. You should consider this as you plan a backup strategy that must comply with {% if page.title contains "Cloud" or page.title contains "Serverless" %} [data domiciling]({% link {{site.current_cloud_version}}/data-domiciling.md %}) {% else %} [data domiciling]({% link {{page.version.version}}/data-domiciling.md %}) {% endif %} requirements.

src/current/cockroachcloud/backup-and-restore-overview.md

@@ -217,4 +217,4 @@ For practical examples of running backup and restore jobs, watch the following v
 
 - Considerations for using [backup](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/backup#considerations) and [restore](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/restore#considerations).
 - [Backup collections](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/take-full-and-incremental-backups#backup-collections) for details on how CockroachDB stores backups.
-- [Restoring backups](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/restoring-backups-across-versions) across major versions of CockroachDB.
+- [Restoring backups](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/restoring-backups-across-versions) across major versions of CockroachDB.

src/current/cockroachcloud/cmek.md

@@ -35,7 +35,7 @@ This section describes some of the ways that CMEK can help you protect your data
 
     <ul><li><p>If a CMEK key is destroyed, the cluster's data can't be recovered by you or by CockroachDB {{ site.data.products.cloud }}, even by restoring from a CockroachDB {{ site.data.products.cloud }}-managed backup. After enabling CMEK, do not disable, schedule for destruction, or destroy a CMEK that is in use by clusters. Instead, first rotate the cluster to use a new CMEK or decommission the cluster, and then use your KMS platform's audit logs to verify that the CMEK is no longer being used.</p></li><li><p>To protect against inadvertent data loss, your KMS platform may impose a waiting period before a key is permanently deleted. This waiting period may be configurable when you create the key. Check the documentation for your KMS platform for details about how long before a key deletion is permanent and irreversible.</p></li></ul>
     {{site.data.alerts.end}}
-- **Enforcement of data domiciling and locality requirements**: In a multi-region cluster, you can confine an individual database to a single region or multiple regions. For more information and limitations, see [Data Domiciling with CockroachDB](https://www.cockroachlabs.com/docs/{{site.current_cloud_version}}/data-domiciling). When you enable CMEK on a multi-region cluster, you can optionally assign a separate CMEK key to each region, or use the same CMEK key for multiple related regions.
+- **Enforcement of data domiciling and locality requirements**: In a multi-region cluster, you can confine an individual database to a single region or multiple regions. For more information and limitations, see [Data Domiciling with CockroachDB]({% link {{site.current_cloud_version}}/data-domiciling.md %}). When you enable CMEK on a multi-region cluster, you can optionally assign a separate CMEK key to each region, or use the same CMEK key for multiple related regions.
 - **Enforcement of encryption requirements**: With CMEK, you have control the CMEK key's encryption strength. The CMEK key's size is determined by what your KMS provider supports.
 
     You can use your KMS platform's controls to configure the regions where the CMEK key is available, enable automatic rotation schedules for CMEK keys, and view audit logs that show each time the CMEK key is used by CockroachDB {{ site.data.products.cloud }}. CockroachDB {{ site.data.products.cloud }} does not need any visibility into these details.