Files
Groene AIandClaude Opus 5.5 f8cbc530ec Generate the implicit min-max indices of a table stored before 25.12 instead of reading them
Versions before 25.12 serialized implicit min-max indices into the table definition
(after any ALTER) and into Keeper metadata. The loader analyzed such a stored index as a
regular one and then re-marked every index with the reserved name as implicit, so:

- once the dictionary, `Join` table or function used by an ALIAS was gone (or, for an
  executable function, not yet registered at startup), the table could not be loaded,
  and a replica stayed read-only because `parseAndNormalize` analyzed the stored
  definition too;
- for an ALIAS expression column (`b ALIAS key * 2`), `addImplicitIndicesForColumn` did not
  recognize the stored index (its `column_names` holds the columns of the expression) and
  generated it a second time, so loading failed with
  `Index with name auto_minmax_index_b already exists` even with every object present
  (measured on 25.8, 26.3, 26.8 and 26.9 with a table written and altered by 25.8);
- a stored implicit index over a non-deterministic `joinGet` / `dictGet` ALIAS was kept,
  although such an index is never generated;
- an index with the reserved name but another shape (e.g. `GRANULARITY 8` from a
  full-definition `ATTACH`) was re-marked implicit, so the next ALTER dropped it from the
  definition and the next load generated it with granularity 1, after which reading it
  failed with `Cannot read all marks`.

Now a stored index identical to the one the generator builds is skipped without analysis,
in `registerStorageMergeTree` (it is generated below exactly as for a table created now)
and in `parseAndNormalize` (stripped from Keeper metadata); any other index is a regular
index on both sides.

The upgrade test creates and alters the table on 25.10; the executable function case
attaches the stored form of the definition.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-15 01:01:41 +00:00
..