Re: Test tidscan,sql is not immune to autovacuum in v14

On Thu, 20 Aug 2026 at 12:32, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 20 Aug 2026 at 08:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> > 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;
>
> I experimented, and I see the costs come out quite different if that
> were changed to:
>
> SELECT count(*) FROM tenk1 WHERE ctid IN (SELECT DISTINCT ctid FROM tenk1);

Here's that patchified.

David