[samgbafa]

TC-1274. Adds the node migration that matches the production index Sam is building online, idx_epoch_order_space_parent_child ON epoch_order (space, parent, child). With it, main matches prod, and fresh databases get the index.

Behaviour

Database state at boot	What m20261017_000000_epoch_order_space_index does
Fresh database	Creates the index on an empty table. Instant.
PostgreSQL, a valid btree index of that name on (space, parent, child) already exists (operator-built)	Reads pg_index and issues no DDL. It takes no lock on epoch_order, and the index keeps its OID.
PostgreSQL, an index of that name that is INVALID (failed CONCURRENTLY), or has a different shape (columns, method, predicate or expressions)	Boot fails. Nothing is applied, and the error gives the DROP INDEX CONCURRENTLY / CREATE INDEX CONCURRENTLY fix.
Existing database without the index	Builds it with a plain CREATE INDEX inside the boot migration transaction. The SHARE lock on epoch_order blocks writes for the whole build, and holds until every pending migration commits. Waiting for that lock is bounded by the 30 s lock_timeout from #316 (TC-1176). The build itself is not bounded.
MySQL	Checks the name with has_index, then creates the index. MySQL has no CREATE INDEX IF NOT EXISTS, and sea-query silently drops the clause.

The pg_index pre-check exists because a bare CREATE INDEX IF NOT EXISTS still takes epoch_order's SHARE lock before it checks the name, and the migration transaction holds that lock until commit. The test below shows this: the naive if_not_exists version blocks behind an open writer.

down() keeps the index. It may be operator-built, and older releases run the same anti-join.

This does not copy m20261015's drop-then-create pattern.

Runbook (PostgreSQL, before upgrading any node that has history)

Run this in autocommit (psql, no BEGIN):

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_epoch_order_space_parent_child ON epoch_order (space, parent, child);
SELECT indisvalid FROM pg_index WHERE indexrelid = 'idx_epoch_order_space_parent_child'::regclass;  -- must be t
-- if f: DROP INDEX CONCURRENTLY idx_epoch_order_space_parent_child; then rebuild

If you upgrade without it, the boot builds the index under a write-blocking lock.

Tests (RED first)

• generated_create_index_statements: the exact PG, SQLite and MySQL DDL. This is MySQL's only coverage, because the full MySQL migration chain fails on init_tables with error 1074 (TC-1314, a known release caveat; I reproduced it on MySQL 8.4.7).
• SQLite:
  • fresh database;
  • v1.20.6 upgrade (first 25 migrations, with seeded history);
  • pre-existing index kept (same rootpage).
• PostgreSQL, through the production db::migrate entry point:
  • fresh database (valid, columns space,parent,child);
  • v1.20.6 upgrade with history;
  • operator CREATE INDEX CONCURRENTLY index kept, same OID, while a writer holds ROW EXCLUSIVE on epoch_order (finishes in under 5 s);
  • INVALID or wrong-column same-name index → DbErr naming the index and DROP INDEX CONCURRENTLY, migration not recorded.

RED evidence, native PG 18.6:

• With a no-op stub, 5 of the 8 tests fail.
• With a naive create_index(..if_not_exists()), postgres_operator_built_index_is_kept_without_blocking_writers fails (blocked behind the writer) and postgres_unusable_operator_index_fails_the_migration fails (the INVALID index is accepted).
• The final version passes 8/8. cargo test -p tinycloud-core --lib migrations passes 18/18. cargo clippy -p tinycloud-core --all-targets -D warnings and fmt --check are clean.

Also: m20261015's lock-timeout test used Migrator::down(Some(1)) and so assumed it was the last migration. It now rolls back to just before itself.

No merge or deploy is implied.

[samgbafa]

APPROVE: see TC-1274 (head 4e371d756751c6fb6f6b162fdd3e1d0789466ddc). Review: https://linear.app/tinycloud-labs/issue/TC-1274/investigate-sam-owner-sql-read-stalls-across-node-hosts#comment-b2453ff1

[samgbafa]

APPROVE: see TC-1274 (delta 4e371d7..d21be15, head d21be15d3c4d16e21140a1862bec6b9493141744). Review: https://linear.app/tinycloud-labs/issue/TC-1274/investigate-sam-owner-sql-read-stalls-across-node-hosts#comment-b43b9571