ForcePlanFailuresAccessPathTests' index-only-scan assertion fails in a full live run, passes alone #3945

Summary

ForcePlanFailuresAccessPathTests.TheShippedRead_PlansAsAnIndexOnlyScanOnTheCoveringIndex_AgainstDevPostgres fails in a full live Darling.Tests run and passes on its own.

Evidence

Measured on a PostgreSQL 18.4 + TimescaleDB 2.28.1 rig, with DARLING_TEST_PG set:

The failure is always the same. The plan is a Merge Join on p.database_name = n.database_name ... with no Index Only Scan:

Assert.Contains() Failure: Sub-string not found
String:    "Merge Join\r\n  Merge Cond: ((p.database_name = n.da"...
Not found: "Index Only Scan"
ForcePlanFailuresAccessPathTests.cs(224,0)

Likely cause (not verified)

The test runs VACUUM ANALYZE collect.query_store_stats and then EXPLAINs the read. It expects the covering index to win because the visibility map is current. In a full run, another test that holds a long snapshot at the same moment would hold back the xmin horizon. The VACUUM could then not mark the new pages all-visible, the index-only scan would be priced with heap fetches, and the plan would flip. The pg_wait_sampling service-arm test runs a 30-second sampling window, which makes it a candidate.

Worth checking pg_class.relallvisible for the seeded chunk just before the EXPLAIN when the class fails.

Also seen in the baseline run

CollectionHealthAggregateTests.InstallHole_FirstPolicyRunAfterEnsure_StrandsNoHistory_AgainstDevPostgres failed once in the same baseline full run. It passed in two full runs of the #3895 branch.