fix(operator): index recovery waits for the interrupted PostgreSQL statement

[krzysztof-smartdataengines]

Summary

Resume and abandonment of a PostgreSQL in-place index build now wait for the interrupted statement
before they read the catalogue. Before, they read the catalogue while a budget-interrupted or
killed operator's CREATE INDEX CONCURRENTLY still ran in the server. Recovery then raced that
statement's commit and failed with "tuple concurrently updated", or dropped the index it was
finishing. This is in 0.1.0.

How it was found

CI on #99 (Python 3.12) failed in
test_the_build_budget_bounds_a_held_build_and_recovery_finishes_it[postgres]:
DROP INDEX CONCURRENTLY "sde_i_…_000001" raised tuple concurrently updated, and recovery
reported index build recovery remains incomplete; preserve its state. The same suite passed on
the other three Pythons and locally. The test's exact sequence, repeated 20 times locally, did not
fail once.

What was measured (PostgreSQL 15.19)

A probe watched pg_stat_activity, pg_stat_progress_create_index and pg_index through a
budget-ended build:

• After the budget and the reconnect, the build's backend is still active. It waits on
  virtualxid in waiting for old snapshots, and the index is not valid.
• Right after the snapshot is released, the backend is active in IO/WALSync, and its
  progress row is gone.
• About 0.1 s later, the index is valid and the backend has exited.

The server notices a vanished client only when it next talks to it. For a concurrent build, that
is once the index is valid. DefineIndex releases the table's session lock before that last
transaction commits. A DROP INDEX CONCURRENTLY that was waiting for the lock starts in that
window, and it updates the pg_index row the build has not committed yet.

docs/in-place-index.md already promised "recovery waits for it, and keeps what it finished or
drops what it left unfinished". The code read the catalogue first, then waited only through the
drop's lock.

The change

• NativeIndexBuild.settle: on PostgreSQL it waits until no active statement names the index
  (pg_stat_activity, the quoted bound name, not its own backend). The operator's deadline bounds
  the wait.
• build and drop settle before they inspect. After the wait, what the statement finished is
  kept, and what it left unfinished is dropped and built again.
• remove does not settle, and says why. Two drops of one index are serialized by the exclusive
  lock the first holds on it until it commits, and
  test_a_resumed_removal_waits_for_the_stopped_drop_and_finishes pins that. Mutation M4 below shows
  a settle there would break it.
• One limit is documented: pg_stat_activity shows a statement's text only to its own login.

Tests

Two new live tests use a killed operator whose build still runs in the server. Neither calls
pg_terminate_backend. The snapshot is released a second into recovery or abandonment:

• test_recovery_waits_for_a_killed_operators_build_and_keeps_what_it_finished checks that no drop
  is active before the release, that the outcome is built, and that the index has the same oid,
  so it was kept, not rebuilt.
• test_abandoning_waits_for_a_killed_operators_build_before_dropping_it checks that no drop is
  active before the release, that the outcome is abandoned, and that the index is absent.

Before the change, both failed deterministically with the CI's tuple concurrently updated. The
budget test also asserts that the recovered index is the one the interrupted statement finished.

Mutations, each alone, restored from a copy kept beside the file:

Mutation	Test	Result
M1: build does not settle	recovery beside the killed build	red, tuple concurrently updated and recovery incomplete
M2: drop does not settle	abandonment beside the killed build	red, tuple concurrently updated and abandonment incomplete
M3: settle waits for idle statements, not active ones	both	red, both, with the same error
M4: remove settles too	test_a_resumed_removal_waits_for_the_stopped_drop_and_finishes	red, the resume waited for the stopped drop past its 6 s budget
C1 (control): poll every 0.05 s instead of 0.2 s	all three	green

C1 is the one that must survive, and it does.

Results

make check with both live engines on 02d0b99:

• ruff and mypy are clean;
• Python: 2103 passed, which is the 2101 of main plus the two new tests, and 10 skipped (the
  orderbook slice);
• TypeScript: 999 of 999.

The index operator and index change files alone passed 119 of 119 with the fix, including the
removal test that M4 breaks.

🤖 Generated with Claude Code