Merge remote-tracking branch 'origin/molt-replicator' into molt-replicator

Author: taroface

src/current/_data/releases.yml

@@ -9645,13 +9645,6 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v24.1.24
-  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.3.21
@@ -9680,13 +9673,6 @@
     docker_arm_limited_access: false
   source: true
   previous_release: v24.3.20
-  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: v25.2.7
@@ -9723,7 +9709,7 @@
       a CockroachDB self-hosted cluster to this version,
       [contact support](https://support.cockroachlabs.com/hc/requests/new).
 
-      
+
 - release_name: v25.3.3
   major_version: v25.3
   release_date: '2025-10-17'
@@ -9756,4 +9742,32 @@
       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).
+      [contact support](https://support.cockroachlabs.com/hc/requests/new).
+
+
+- release_name: v25.4.0-rc.1
+  major_version: v25.4
+  release_date: '2025-10-22'
+  release_type: Testing
+  go_version: go1.23.12
+  sha: 1de9c4bc217dca385a4f912dbdf828bc5629711a
+  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: v25.4.0-beta.3

src/current/_includes/common/upgrade/finalize-self-hosted.md

@@ -13,7 +13,7 @@ To finalize a major-version upgrade:
 
     {% include_cached copy-clipboard.html %}
     ~~~ sql
-    SET CLUSTER SETTING version '{VERSION}';
+    SET CLUSTER SETTING version = '{VERSION}';
     ~~~
 
     A series of migration jobs runs to enable certain types of features and changes in the new major version that cannot be rolled back. These include changes to system schemas, indexes, and descriptors, and enabling certain types of improvements and new features. Until the upgrade is finalized, these features and functions will not be available and the command `SHOW CLUSTER SETTING version` will return the previous version.

src/current/_includes/molt/migration-schema-design-practices.md

@@ -32,6 +32,10 @@ Convert the source schema into a CockroachDB-compatible schema. CockroachDB supp
 
 - Every table **must** have an explicit primary key. For more information, refer to [Primary key best practices]({% link {{ site.current_cloud_version }}/schema-design-table.md %}#primary-key-best-practices).
 
+	{{site.data.alerts.callout_danger}}
+	Avoid using sequential keys. To learn more about the performance issues that can result from their use, refer to the [guidance on indexing with sequential keys]({% link {{site.current_cloud_version}}/sql-faqs.md %}#how-do-i-generate-unique-slowly-increasing-sequential-numbers-in-cockroachdb). If a sequential key is necessary in your CockroachDB table, you must create it manually, after using [MOLT Fetch]({% link molt/molt-fetch.md %}) to load and replicate the data.
+	{{site.data.alerts.end}}
+
 - Review [Transformations]({% link molt/molt-fetch.md %}#transformations) to understand how computed columns and partitioned tables can be mapped to the target, and how target tables can be renamed.
 
 - By default on CockroachDB, `INT` is an alias for `INT8`, which creates 64-bit signed integers. PostgreSQL and MySQL default to 32-bit integers. Depending on your source database or application requirements, you may need to change the integer size to `4`. For more information, refer to [Considerations for 64-bit signed integers]({% link {{ site.current_cloud_version }}/int.md %}#considerations-for-64-bit-signed-integers).

src/current/_includes/releases/v25.4/v25.4.0-rc.1.md

@@ -0,0 +1,49 @@
+## v25.4.0-rc.1
+
+Release Date: October 22, 2025
+
+{% include releases/new-release-downloads-docker-image.md release=include.release %}
+
+<h3 id="v25-4-0-rc-1-sql-language-changes">SQL language changes</h3>
+
+- Changed scan misestimate logging gated behind
+  `sql.log.scan_row_count_misestimate.enabled` to use structured logging
+  including the table and index being scanned, the estimated and actual
+  row counts, the time since the last table stats collection, and the
+  table's estimated staleness. [#155123][#155123]
+- Added a default-off cluster setting
+  (`sql.log.scan_row_count_misestimate.enabled`) that enables logging a
+  warning on the gateway node when optimizer estimates for scans are
+  inaccurate. The log message includes the table and index being scanned,
+  the estimated and actual row counts, the time since the last table stats
+  collection, and the table's estimated staleness. [#155123][#155123]
+- Added the `INSPECT` command, which runs consistency validation check jobs against tables or databases and specified indexes. [#155441][#155441]
+- Added the
+  `bulkio.index_backfill.vector_merge_batch_size cluster` setting to control
+  how many vectors to merge into a vector index per transaction during
+  create operations. By default, this defaults to 3. [#155509][#155509]
+- Vector indexing is now enabled by default. [#155561][#155561]
+
+<h3 id="v25-4-0-rc-1-bug-fixes">Bug fixes</h3>
+
+- Fixed a bug that caused internal errors for `INSERT .. ON CONFLICT .. DO UPDATE` statements when the target table had both a computed column and a `BEFORE` trigger. This bug was present since triggers were introduced in v24.3.0. [#155077][#155077]
+- Disable a feature
+  (`kv.lock_table.unreplicated_lock_reliability.split.enabled`) that could
+  lead to a node crash. [#155366][#155366]
+- Previously, we could corrupt the first bucket of
+  table statistic histograms in certain cases, causing underestimates for
+  range counts near the lower end of the domain, which is now fixed. [#155415][#155415]
+- A potential deadlock during vector index
+  creation has been corrected. [#155508][#155508]
+- Added proper dependency handling when adding a constraint with `NOT VALID` that references a user-defined function (UDF). [#155528][#155528]
+
+
+[#155123]: https://github.com/cockroachdb/cockroach/pull/155123
+[#155441]: https://github.com/cockroachdb/cockroach/pull/155441
+[#155508]: https://github.com/cockroachdb/cockroach/pull/155508
+[#155509]: https://github.com/cockroachdb/cockroach/pull/155509
+[#155561]: https://github.com/cockroachdb/cockroach/pull/155561
+[#155077]: https://github.com/cockroachdb/cockroach/pull/155077
+[#155366]: https://github.com/cockroachdb/cockroach/pull/155366
+[#155415]: https://github.com/cockroachdb/cockroach/pull/155415
+[#155528]: https://github.com/cockroachdb/cockroach/pull/155528

src/current/_includes/v25.4/sidebar-data/sql.json

@@ -40,6 +40,12 @@
                 "/${VERSION}/alter-default-privileges.html"
               ]
             },
+            {
+              "title": "<code>ALTER EXTERNAL CONNECTION</code>",
+              "urls": [
+                "/${VERSION}/alter-external-connection.html"
+              ]
+            },
             {
               "title": "<code>ALTER FUNCTION</code>",
               "urls": [

src/current/v23.2/architecture/life-of-a-distributed-transaction.md

@@ -116,7 +116,7 @@ The batch evaluator ensures that write operations are valid. Our architecture ma
 
 If the write operation is valid according to the evaluator, the leaseholder sends a provisional acknowledgment to the gateway node's `DistSender`; this lets the `DistSender` begin to send its subsequent `BatchRequests` for this range.
 
-Importantly, this feature is entirely built for transactional optimization (known as [transaction pipelining]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#transaction-pipelining)). There are no issues if an operation passes the evaluator but doesn't end up committing.
+Importantly, this feature is entirely built for transactional optimization (known as [transaction pipelining]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#transaction-pipelining)). For important caveats about what pipelining does and does not change in end-to-end latency, see that section. There are no issues if an operation passes the evaluator but doesn't end up committing.
 
 ### Reads from the storage layer
 

src/current/v23.2/architecture/transaction-layer.md

@@ -338,7 +338,7 @@ The check is done by keeping track of all the reads using a dedicated `RefreshRe
 
 ### Transaction pipelining
 
-Transactional writes are pipelined when being replicated and when being written to disk, dramatically reducing the latency of transactions that perform multiple writes. For example, consider the following transaction:
+Transactional writes are pipelined when being [replicated]({% link {{ page.version.version }}/architecture/replication-layer.md %}) and when being written to disk, dramatically reducing the latency of transactions that perform multiple writes. For example, consider the following transaction:
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
@@ -350,19 +350,21 @@ INSERT into kv (key, value) VALUES ('orange', 'orange');
 COMMIT;
 ~~~
 
-With transaction pipelining, write intents are replicated from leaseholders in parallel, so the waiting all happens at the end, at transaction commit time.
+With transaction pipelining, [write intents](#write-intents) are replicated from [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) in parallel, so most of the waiting happens at the end, at transaction commit time.
 
 At a high level, transaction pipelining works as follows:
 
-1. For each statement, the transaction gateway node communicates with the leaseholders (*L*<sub>1</sub>, *L*<sub>2</sub>, *L*<sub>3</sub>, ..., *L*<sub>i</sub>) for the ranges it wants to write to. Since the primary keys in the table above are UUIDs, the ranges are probably split across multiple leaseholders (this is a good thing, as it decreases [transaction conflicts](#transaction-conflicts)).
+1. For each statement, the transaction gateway node communicates with the leaseholders (*L*<sub>1</sub>, *L*<sub>2</sub>, *L*<sub>3</sub>, ..., *L*<sub>i</sub>) for the [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) it wants to write to. Since the [primary keys]({% link {{ page.version.version }}/primary-key.md %}) in the table above are UUIDs, the ranges are probably split across multiple leaseholders (this is a good thing, as it decreases [transaction conflicts](#transaction-conflicts)).
 
-1. Each leaseholder *L*<sub>i</sub> receives the communication from the transaction gateway node and does the following in parallel:
+1. Each leaseholder *L*<sub>i</sub> receives the communication from the transaction [gateway node]({% link {{ page.version.version }}/architecture/sql-layer.md %}#gateway-node) and does the following in parallel:
   - Creates write intents and sends them to its follower nodes.
   - Responds to the transaction gateway node that the write intents have been sent. Note that replication of the intents is still in-flight at this stage.
 
 1. When attempting to commit, the transaction gateway node then waits for the write intents to be replicated in parallel to all of the leaseholders' followers. When it receives responses from the leaseholders that the write intents have propagated, it commits the transaction.
 
-In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means that the cost of multiple writes is not `O(n)` in the number of SQL DML statements; instead, it's `O(1)`.
+In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means the consensus-related waiting is not `O(n)` in the number of SQL DML statements; instead, it approaches `O(1)`.
+
+However, client-observed latency still includes a certain amount of per-statement work that must be performed. For example, although transaction pipelining parallelizes the [Raft]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft) consensus work for [write intents](#write-intents) across statements, each statement must be [planned and evaluated]({% link {{ page.version.version }}/architecture/sql-layer.md %}). This includes scanning [indexes]({% link {{ page.version.version }}/indexes.md %}), checking [constraints]({% link {{ page.version.version }}/constraints.md %}), detecting [conflicts](#transaction-conflicts), and waiting on [contending writes]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#understanding-and-avoiding-transaction-contention). The client still submits statements sequentially. Statements that touch the same rows can also create pipeline stalls to preserve [read-your-writes](https://jepsen.io/consistency/models/read-your-writes) ordering. As a result, while the consensus component of write latency can approach `O(1)` with respect to the number of statements, end-to-end transaction latency can still increase with the number of statements.
 
 ### Parallel Commits
 

src/current/v24.1/architecture/life-of-a-distributed-transaction.md

@@ -116,7 +116,7 @@ The batch evaluator ensures that write operations are valid. Our architecture ma
 
 If the write operation is valid according to the evaluator, the leaseholder sends a provisional acknowledgment to the gateway node's `DistSender`; this lets the `DistSender` begin to send its subsequent `BatchRequests` for this range.
 
-Importantly, this feature is entirely built for transactional optimization (known as [transaction pipelining]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#transaction-pipelining)). There are no issues if an operation passes the evaluator but doesn't end up committing.
+Importantly, this feature is entirely built for transactional optimization (known as [transaction pipelining]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#transaction-pipelining)). For important caveats about what pipelining does and does not change in end-to-end latency, see that section. There are no issues if an operation passes the evaluator but doesn't end up committing.
 
 ### Reads from the storage layer
 

src/current/v24.1/architecture/transaction-layer.md

@@ -338,7 +338,7 @@ The check is done by keeping track of all the reads using a dedicated `RefreshRe
 
 ### Transaction pipelining
 
-Transactional writes are pipelined when being replicated and when being written to disk, dramatically reducing the latency of transactions that perform multiple writes. For example, consider the following transaction:
+Transactional writes are pipelined when being [replicated]({% link {{ page.version.version }}/architecture/replication-layer.md %}) and when being written to disk, dramatically reducing the latency of transactions that perform multiple writes. For example, consider the following transaction:
 
 {% include_cached copy-clipboard.html %}
 ~~~ sql
@@ -350,19 +350,21 @@ INSERT into kv (key, value) VALUES ('orange', 'orange');
 COMMIT;
 ~~~
 
-With transaction pipelining, write intents are replicated from leaseholders in parallel, so the waiting all happens at the end, at transaction commit time.
+With transaction pipelining, [write intents](#write-intents) are replicated from [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) in parallel, so most of the waiting happens at the end, at transaction commit time.
 
 At a high level, transaction pipelining works as follows:
 
-1. For each statement, the transaction gateway node communicates with the leaseholders (*L*<sub>1</sub>, *L*<sub>2</sub>, *L*<sub>3</sub>, ..., *L*<sub>i</sub>) for the ranges it wants to write to. Since the primary keys in the table above are UUIDs, the ranges are probably split across multiple leaseholders (this is a good thing, as it decreases [transaction conflicts](#transaction-conflicts)).
+1. For each statement, the transaction gateway node communicates with the leaseholders (*L*<sub>1</sub>, *L*<sub>2</sub>, *L*<sub>3</sub>, ..., *L*<sub>i</sub>) for the [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) it wants to write to. Since the [primary keys]({% link {{ page.version.version }}/primary-key.md %}) in the table above are UUIDs, the ranges are probably split across multiple leaseholders (this is a good thing, as it decreases [transaction conflicts](#transaction-conflicts)).
 
-1. Each leaseholder *L*<sub>i</sub> receives the communication from the transaction gateway node and does the following in parallel:
+1. Each leaseholder *L*<sub>i</sub> receives the communication from the transaction [gateway node]({% link {{ page.version.version }}/architecture/sql-layer.md %}#gateway-node) and does the following in parallel:
   - Creates write intents and sends them to its follower nodes.
   - Responds to the transaction gateway node that the write intents have been sent. Note that replication of the intents is still in-flight at this stage.
 
 1. When attempting to commit, the transaction gateway node then waits for the write intents to be replicated in parallel to all of the leaseholders' followers. When it receives responses from the leaseholders that the write intents have propagated, it commits the transaction.
 
-In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means that the cost of multiple writes is not `O(n)` in the number of SQL DML statements; instead, it's `O(1)`.
+In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means the consensus-related waiting is not `O(n)` in the number of SQL DML statements; instead, it approaches `O(1)`.
+
+However, client-observed latency still includes a certain amount of per-statement work that must be performed. For example, although transaction pipelining parallelizes the [Raft]({% link {{ page.version.version }}/architecture/replication-layer.md %}#raft) consensus work for [write intents](#write-intents) across statements, each statement must be [planned and evaluated]({% link {{ page.version.version }}/architecture/sql-layer.md %}). This includes scanning [indexes]({% link {{ page.version.version }}/indexes.md %}), checking [constraints]({% link {{ page.version.version }}/constraints.md %}), detecting [conflicts](#transaction-conflicts), and waiting on [contending writes]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#understanding-and-avoiding-transaction-contention). The client still submits statements sequentially. Statements that touch the same rows can also create pipeline stalls to preserve [read-your-writes](https://jepsen.io/consistency/models/read-your-writes) ordering. As a result, while the consensus component of write latency can approach `O(1)` with respect to the number of statements, end-to-end transaction latency can still increase with the number of statements.
 
 ### Parallel Commits