The collection-health fixture stops its scratch database's TimescaleDB scheduler, so no policy run the test did not make can land (#3986)

[erikdarlingdata]

Closes #3986.

Why

collection_health_hourly's refresh policy has no initial_start, so TimescaleDB's scheduler launches its first run as soon as the product's ensure path commits it. CollectionHealthAggregateTests.OpenStoreAsync could park the job only after that. A launch that landed first either:

• collided with the test's CALL run_job (55P03, The start-up hole scan probes each bucket once instead of joining the whole materialization and the whole source table (#3933) #3972's CI run), which Chunk-exclusion tests count a bitmap plan's chunks once, and the collection-health policy run waits out a launch that beat the park #3982 retried; or
• refreshed while the test was still planting, moving the watermark under rows a pre-run assertion then missed. OutageHole_… saw 342 of 360. The retry could not help with that.

What changes

• OpenStoreAsync calls _timescaledb_functions.stop_background_workers() on the scratch database before the ensure path runs, then asserts that no TimescaleDB scheduler remains for that database. The park stays as a second guard.
• RunPolicyAsync loses Chunk-exclusion tests count a bitmap plan's chunks once, and the collection-health policy run waits out a launch that beat the park #3982's 55P03 retry. With no background run possible, it was dead code, and its comment claimed more than it covered.
• FreshStoreWatermarkTests shares the fixture and gets the same guarantee.

Test plan

• Measured on a PostgreSQL 18.4 + TimescaleDB 2.28.1 rig (this machine's stale pg-runtime.zip; CI's darling-pg job then ran the fixture on the pinned 2.30.1 runtime and passed, and The collection-health fixture's comment names the TimescaleDB version it was measured on (#3986 follow-up) #3988 corrects the code comment), using two probe databases, each with a CAGG and a policy with no initial_start:
  • stop_background_workers() stopped only its own database's scheduler; the other database's stayed up.
  • With the stop, the policy never ran on its own, total_runs stayed null and 0 buckets were materialized, and CALL run_job then materialized 47.
  • The control database's policy ran on its own within 15 s: 1 run, 47 buckets. That is the launch this fixture was racing.
• CollectionHealthAggregateTests + FreshStoreWatermarkTests live on that rig, run five times in a row: 15/15 each time.
• Build: 0 warnings.
• CI's darling-pg full run.

Test-only change, so no CHANGELOG entry.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv