Merge remote-tracking branch 'origin/main' into DOC-14614

florence-crl · florence-crl · commit 6ccbe81038b3 · 2025-10-31T14:53:01.000-04:00
diff --git a/src/current/_data/releases.yml b/src/current/_data/releases.yml
@@ -9767,3 +9767,84 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v25.4.0-beta.3
+
+- release_name: v24.3.22
+  major_version: v24.3
+  release_date: '2025-10-30'
+  release_type: Production
+  go_version: go1.25.3
+  sha: 303aedc82bbb8ef1b70f10cd91fcfc01d967d799
+  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
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v24.3.21
+
+- release_name: v25.2.8
+  major_version: v25.2
+  release_date: '2025-10-30'
+  release_type: Production
+  go_version: go1.25.3
+  sha: 74dbb7ba6b71f6d336334f8fa6f5d002506a49d4
+  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
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v25.2.7
+
+- release_name: v25.3.4
+  major_version: v25.3
+  release_date: '2025-10-30'
+  release_type: Production
+  go_version: go1.25.3
+  sha: 1cddb3a22695e967197844b214115eb645473efe
+  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
+    docker_arm: true
+    docker_arm_experimental: false
+    docker_arm_limited_access: false
+  source: true
+  previous_release: v25.3.3
diff --git a/src/current/_includes/releases/v24.3/v24.3.22.md b/src/current/_includes/releases/v24.3/v24.3.22.md
@@ -0,0 +1,11 @@
+## v24.3.22
+
+Release Date: October 30, 2025
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v24-3-22-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug in the `cockroach node drain` command where draining a node using virtual clusters (such as clusters running Physical Cluster Replication (PCR)) could return before the drain was complete, possibly resulting in shutting down the node while it still had active SQL clients and range leases. [#156311][#156311]
+
+[#156311]: https://github.com/cockroachdb/cockroach/pull/156311
diff --git a/src/current/_includes/releases/v25.2/v25.2.8.md b/src/current/_includes/releases/v25.2/v25.2.8.md
@@ -0,0 +1,16 @@
+## v25.2.8
+
+Release Date: October 30, 2025
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v25-2-8-operational-changes">Operational changes</h3>
+
+- In order to selectively capture traces for transactions running in an active workload without having to capture them via statement diagnostic bundles, customers can now use the `sql.trace.txn.sample_rate` cluster setting to enable tracing for a fraction of their workload. The `sql.trace.txn.enable_threshold` will still need to be set to a positive value to provide a filter for how slow a transaction needs to be after being sampled to merit emitting a trace. Traces are emitted to the `SQL_EXEC` logging channel. [#156409][#156409]
+
+<h3 id="v25-2-8-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug in the `cockroach node drain` command where draining a node using virtual clusters (such as clusters running Physical Cluster Replication (PCR)) could return before the drain was complete, possibly resulting in shutting down the node while it still had active SQL clients and range leases. [#156312][#156312]
+
+[#156409]: https://github.com/cockroachdb/cockroach/pull/156409
+[#156312]: https://github.com/cockroachdb/cockroach/pull/156312
diff --git a/src/current/_includes/releases/v25.3/v25.3.4.md b/src/current/_includes/releases/v25.3/v25.3.4.md
@@ -0,0 +1,11 @@
+## v25.3.4
+
+Release Date: October 30, 2025
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v25-3-4-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug in the `cockroach node drain` command where draining a node using virtual clusters (such as clusters running Physical Cluster Replication (PCR)) could return before the drain was complete, possibly resulting in shutting down the node while it still had active SQL clients and range leases. [#156313][#156313]
+
+[#156313]: https://github.com/cockroachdb/cockroach/pull/156313
diff --git a/src/current/_includes/releases/v25.4/v25.4.0-beta.2.md b/src/current/_includes/releases/v25.4/v25.4.0-beta.2.md
@@ -13,18 +13,18 @@ Release Date: October 10, 2025
 
 - Added the `SHOW INSPECT ERRORS` command. This command can be used to view issues that are identified by running the `INSPECT` command to validate tables and indexes. [#154337][#154337]
 - Added the `sql.catalog.allow_leased_descriptors.enabled` cluster setting, which is false by default. When set to true, queries that access the `pg_catalog` or `information_schema` can use cached leased descriptors to populate the data in those tables, with the tradeoff that some of the data could be stale. [#154491][#154491]
-- We now support index acceleration for a subset of jsonb_path_exists filters. Given the `jsonb_path_exists(json_obj, json_path_expression)`, we only support inverted index for json_path_expression that matches one of the following patterns:
-  - The json_path_expression must NOT be in STRICT mode.
-  - keychain mode: $.[key|wildcard].[key|wildcard]...
-  	- For this mode, we will generate a prefix span for the inverted expression.
-  - filter with end value mode, with equality check: $.[key|wildcard]? (@.[key|wildcard].[key|wildcard]... == [string|number|null|boolean])
-      - For this mode, since the end value is fixed, we will generate a single value span.
-  - Specifically, we don't support the following edge case:
-      - $
-      - $[*]
-      - $.a.b.c == 12 or $.a.b.c > 12 or $.a.b.c < 12 (operation expression)
-      - $.a.b ? (@.a > 10) (filter, with inequality check)
-  - Note that the cases we support is to use `jsonb_path_exists` in filters, as in, when they are used in the WHERE clause. [#154631][#154631]
+- CockroachDB now supports index acceleration for certain `jsonb_path_exists` filters used in `WHERE` clauses. Given `jsonb_path_exists(json_obj, json_path_expression)`, an inverted index is supported only when `json_path_expression` matches one of the following patterns:
+  - The `json_path_expression` must **not** be in `strict` mode.
+  - Keychain mode: `$.[key|wildcard].[key|wildcard]...`
+    - In this mode, a prefix span is generated for the inverted expression.
+  - Filter with end value mode (equality check): `$.[key|wildcard]? (@.[key|wildcard].[key|wildcard]... == [string|number|null|boolean])`
+    - In this mode, since the end value is fixed, a single value span is generated.
+  - The following edge cases are **not** supported:
+      - `$`
+      - `$[*]`
+      - `$.a.b.c == 12`, `$.a.b.c > 12`, or `$.a.b.c < 12` (operation expressions)
+      - `$.a.b ? (@.a > 10)` (filter with inequality check)
+  [#154631][#154631]
 - The optimizer can now use table statistics that merge the latest full statistic with all newer partial statistics, including those over arbitrary constraints over a single span. [#154755][#154755]
 
 <h3 id="v25-4-0-beta-2-operational-changes">Operational changes</h3>
diff --git a/src/current/_includes/v24.1/faq/clock-synchronization-effects.md b/src/current/_includes/v24.1/faq/clock-synchronization-effects.md
@@ -2,7 +2,7 @@ CockroachDB requires moderate levels of clock synchronization to preserve data c
 
 Regardless of clock skew, [`SERIALIZABLE`]({% link {{ page.version.version }}/demo-serializable.md %}) and [`READ COMMITTED`]({% link {{ page.version.version }}/read-committed.md %}) transactions both serve globally consistent ("non-stale") reads and [commit atomically]({% link {{ page.version.version }}/developer-basics.md %}#how-transactions-work-in-cockroachdb). However, skew outside the configured clock offset bounds can result in violations of single-key linearizability between causally dependent transactions. It's therefore important to prevent clocks from drifting too far by running [NTP](http://www.ntp.org/) or other clock synchronization software on each node.
 
-In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, see [this blog post](https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
+In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, refer to [this blog post](https://web.archive.org/web/20210420062611/https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
 
 {{site.data.alerts.callout_danger}}
 In CockroachDB versions prior to v22.2.13, and in v23.1 versions prior to v23.1.9, the [`--clock-device`](cockroach-start.html#general) flag had a bug that could cause it to generate timestamps in the far future. This could cause nodes to crash due to incorrect timestamps, or in the worst case irreversibly advance the cluster's HLC clock into the far future. This bug is fixed in CockroachDB v23.2.
diff --git a/src/current/_includes/v24.3/faq/clock-synchronization-effects.md b/src/current/_includes/v24.3/faq/clock-synchronization-effects.md
@@ -2,7 +2,7 @@ CockroachDB requires moderate levels of clock synchronization to preserve data c
 
 Regardless of clock skew, [`SERIALIZABLE`]({% link {{ page.version.version }}/demo-serializable.md %}) and [`READ COMMITTED`]({% link {{ page.version.version }}/read-committed.md %}) transactions both serve globally consistent ("non-stale") reads and [commit atomically]({% link {{ page.version.version }}/developer-basics.md %}#how-transactions-work-in-cockroachdb). However, skew outside the configured clock offset bounds can result in violations of single-key linearizability between causally dependent transactions. It's therefore important to prevent clocks from drifting too far by running [NTP](http://www.ntp.org/) or other clock synchronization software on each node.
 
-In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, see [this blog post](https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
+In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, refer to [this blog post](https://web.archive.org/web/20210420062611/https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
 
 {{site.data.alerts.callout_danger}}
 In CockroachDB versions prior to v22.2.13, and in v23.1 versions prior to v23.1.9, the [`--clock-device`](cockroach-start.html#general) flag had a bug that could cause it to generate timestamps in the far future. This could cause nodes to crash due to incorrect timestamps, or in the worst case irreversibly advance the cluster's HLC clock into the far future. This bug is fixed in CockroachDB v23.2.
diff --git a/src/current/_includes/v25.1/faq/clock-synchronization-effects.md b/src/current/_includes/v25.1/faq/clock-synchronization-effects.md
@@ -2,7 +2,7 @@ CockroachDB requires moderate levels of clock synchronization to preserve data c
 
 Regardless of clock skew, [`SERIALIZABLE`]({% link {{ page.version.version }}/demo-serializable.md %}) and [`READ COMMITTED`]({% link {{ page.version.version }}/read-committed.md %}) transactions both serve globally consistent ("non-stale") reads and [commit atomically]({% link {{ page.version.version }}/developer-basics.md %}#how-transactions-work-in-cockroachdb). However, skew outside the configured clock offset bounds can result in violations of single-key linearizability between causally dependent transactions. It's therefore important to prevent clocks from drifting too far by running [NTP](http://www.ntp.org/) or other clock synchronization software on each node.
 
-In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, see [this blog post](https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
+In very rare cases, CockroachDB can momentarily run with a stale clock. This can happen when using vMotion, which can suspend a VM running CockroachDB, migrate it to different hardware, and resume it. This will cause CockroachDB to be out of sync for a short period before it jumps to the correct time. During this window, it would be possible for a client to read stale data and write data derived from stale reads. By enabling the `server.clock.forward_jump_check_enabled` [cluster setting]({% link {{ page.version.version }}/cluster-settings.md %}), you can be alerted when the CockroachDB clock jumps forward, indicating it had been running with a stale clock. To protect against this on vMotion, however, use the [`--clock-device`](cockroach-start.html#general) flag to specify a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) for CockroachDB to use when querying the current time. When doing so, you should not enable `server.clock.forward_jump_check_enabled` because forward jumps will be expected and harmless. For more information on how `--clock-device` interacts with vMotion, refer to [this blog post](https://web.archive.org/web/20210420062611/https://core.vmware.com/blog/cockroachdb-vmotion-support-vsphere-7-using-precise-timekeeping).
 
 {{site.data.alerts.callout_danger}}
 In CockroachDB versions prior to v22.2.13, and in v23.1 versions prior to v23.1.9, the [`--clock-device`](cockroach-start.html#general) flag had a bug that could cause it to generate timestamps in the far future. This could cause nodes to crash due to incorrect timestamps, or in the worst case irreversibly advance the cluster's HLC clock into the far future. This bug is fixed in CockroachDB v23.2.
diff --git a/src/current/_includes/v25.3/faq/clock-synchronization-effects.md b/src/current/_includes/v25.3/faq/clock-synchronization-effects.md
diff --git a/src/current/_includes/v25.4/faq/clock-synchronization-effects.md b/src/current/_includes/v25.4/faq/clock-synchronization-effects.md
diff --git a/src/current/algolia_index_intelligent_bloat_removal.py b/src/current/algolia_index_intelligent_bloat_removal.py
