CockroachDB 20.2.3 selects compatible nodes for imports
Imports can run in a mixed-version cluster by selecting compatible execution nodes. The patch also repairs partial indexes affected by foreign-key cascades and exposes license expiration through metrics.
A mixed-version cluster and a cluster actively restarting nodes are different environments for a long-running import. CockroachDB 20.2.3 adds support for the first. Paul Bardea's import-planning patch explicitly says it does not add support for an import continuing through a node upgrade. The import job needs to restart in that case. That qualification gives the new capability a more precise meaning than unrestricted importing during a rolling upgrade.
The release catalog and release-day notes date the maintenance release to December 14. Its SQL and operational changes also include descriptor repair functions, license-expiration reporting and a partial-index correctness repair. For installations already on 20.2, that last repair can require rebuilding affected indexes after updating.
I value CockroachDB's explicit coordination model, so this upgrade distinction matters to me. Coexisting binaries need compatible work placement. Restarting a participant introduces another interruption problem. Supporting the former does not establish that the latter leaves every running job uninterrupted.
Bulk planning filters the available nodes
The import patch changes the list returned by setup of all-node planning. Instead of returning every node present in the status map, it returns those whose status is NodeOK. The caller consequently receives nodes considered suitable for the distributed plan, rather than treating membership in the map as evidence of compatibility.
Its mixed-version test upgrades some nodes, preserves the older cluster version and then runs an import. The sequence deliberately exercises a stable mixture of versions. It does not restart a node while the import is executing. That test scope matches the patch's stated limitation and identifies what the new support actually demonstrates.
For a deployment procedure, this creates a usable interval between node upgrades. An import can run while the cluster contains different versions, provided its execution uses compatible nodes. A plan that also restarts those nodes needs to account for the separate restart requirement. The relevant operational state includes both binary versions and whether the import's participants remain available.
Partial indexes need correct cascade maintenance
The partial-index documentation describes an index containing rows satisfying a predicate. The subset is a physical representation maintained as table values change. A cascade from a parent table must therefore update both the child row and any index membership affected by the changed values.
For example, a partial index on an existing child table can select active rows:
CREATE INDEX child_active_parent
ON child_records (parent_id)
WHERE active;
That predicate means not every child row belongs in the index. Updating a referenced parent key can still change an indexed child value through a foreign-key cascade. Correct index maintenance must account for the old and new child values and whether each representation belongs in the partial index.
Marcus Gartner's cascade repair identifies missing synthesized columns used to delete partial-index entries during cascading mutations. Cascading updates could corrupt an index and produce incorrect query results. The patch supplies the required projections and repairs handling of extra execution input columns.
The release guidance says partial indexes on child tables with ON DELETE CASCADE or ON UPDATE CASCADE relationships may be affected and should be dropped and recreated. Installing corrected mutation code prevents future faulty maintenance. Recreating an affected index reconstructs its contents from table data, which addresses a different part of the problem.
The partial-index reference also lists IMPORT on tables with partial indexes as unsupported in this version. Mixed-version planning support does not remove that independent table limitation. This is another reason to state the scope of an import precisely. Compatible execution nodes establish one requirement, while the destination table's supported structure establishes another requirement for the requested operation.
License expiry becomes observable at scrape time
The 20.2.3 metrics handler emits a metric named seconds_until_enterprise_license_expiry. The source calculates it on demand when rendering metrics, using the duration until expiration converted to seconds. This actual emitted name is more specific than the shorter name used in the release notes.
The metric patch explains why the value is computed on demand. There is no regular process maintaining that time series independently. A metrics request therefore evaluates the remaining duration at the time it is served, with negative values representing an expiration in the past.
I prefer this operational signal to requiring an administrator to rediscover the expiration date during unrelated maintenance. An alert can refer to the value the server emits, but it needs the actual metric name. The implementation supplies that concrete contract, while the maintenance release's import and index fixes address separate requirements for work placement and stored query correctness.