Test tidscan,sql is not immune to autovacuum in v14

Hello hackers,

I spotted a very rare test failure (a single one in two years, at least)
generated by basilisk:
     tidscan                      ... FAILED       34 ms
...
diff -U3 /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out
/mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out
--- /mnt/build/REL_14_STABLE/pgsql.build/../pgsql/src/test/regress/expected/tidscan.out
+++ /mnt/build/REL_14_STABLE/pgsql.build/src/test/regress/results/tidscan.out
@@ -242,10 +242,10 @@
 ----------------------------------------
  Aggregate
    ->  Hash Join
-         Hash Cond: (t1.ctid = t2.ctid)
-         ->  Seq Scan on tenk1 t1
+         Hash Cond: (t2.ctid = t1.ctid)
+         ->  Seq Scan on tenk1 t2
          ->  Hash
-               ->  Seq Scan on tenk1 t2
+               ->  Seq Scan on tenk1 t1
 (6 rows)

 SELECT count(*) FROM tenk1 t1 JOIN tenk1 t2 ON t1.ctid = t2.ctid;

and was intrigued enough to find a reliable reproducer for it.
With the following modification:
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -188,6 +188,7 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent,
                estimate_rel_size(relation, rel->attr_widths - rel->min_attr,
&rel->pages, &rel->tuples, &rel->allvisfrac);

+char *name = get_rel_name(relationObjectId); if (name != NULL && strcmp(name, "tenk1") == 0) pg_usleep(100000);
        /* Retrieve the parallel_workers reloption, or -1 if not set. */
        rel->rel_parallel_workers = RelationGetParallelWorkers(relation, -1);

and
test: tidscan analyze
in parallel_schedule (the full patch is attached), I get:
parallel group (2 tests):  analyze tidscan
     tidscan                      ... FAILED      900 ms
     analyze                      ... ok           63 ms

(The basilisk's log contain no autovacuum messages, but I guess it was
automatic analyze that processed tenk1 in the very lucky moment.)

Given the current statistics, we won't see failures of this ilk anymore,
because it is not reproduced in REL_15_STABLE..master, due to 74388a1ac +
4496020e6, which resulted in a different reltuples value returned for tenk1
during sanity_check/VACUUM and that indirectly affected the plan change.

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=basilisk&dt=2026-06-15%2006%3A07%3A09

Best regards,
Alexander