Re: To what extent should tests rely on VACUUM ANALYZE?
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Alexander Korotkov <a.korotkov@postgrespro.ru>,
Thomas Munro <thomas.munro@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Date: 2024-03-29T07:06:07Z
Lists: pgsql-hackers
On Thu, Mar 28, 2024 at 11:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > When running multiple 027_stream_regress.pl test instances in parallel > (and with aggressive autovacuum) on a rather slow machine, I encountered > test failures due to the subselect test instability just as the following > failures on buildfarm: > 1) > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grassquit&dt=2024-03-27%2010%3A16%3A12 > > --- > /home/bf/bf-build/grassquit/HEAD/pgsql/src/test/regress/expected/subselect.out > 2024-03-19 22:20:34.435867114 +0000 > +++ > /home/bf/bf-build/grassquit/HEAD/pgsql.build/testrun/recovery/027_stream_regress/data/results/subselect.out > > 2024-03-27 10:28:38.185776605 +0000 > @@ -2067,16 +2067,16 @@ > QUERY PLAN > ------------------------------------------------- > Hash Join > - Hash Cond: (c.odd = b.odd) > + Hash Cond: (c.hundred = a.hundred) > -> Hash Join > - Hash Cond: (a.hundred = c.hundred) > - -> Seq Scan on tenk1 a > + Hash Cond: (b.odd = c.odd) > + -> Seq Scan on tenk2 b > -> Hash > -> HashAggregate > Group Key: c.odd, c.hundred > -> Seq Scan on tenk2 c > -> Hash > - -> Seq Scan on tenk2 b > + -> Seq Scan on tenk1 a > (11 rows) FWIW, this issue is also being reproduced in Cirrus CI, as Matthias reported in another thread [1] days ago. [1] https://www.postgresql.org/message-id/CAEze2WiiE-iTKxgWQzcjyiiiA4q-zsdkkAdCaD_E83xA2g2BLA%40mail.gmail.com Thanks Richard
Commits
-
Try to stabilize flappy test result.
- c2df2ed90a82 17.0 landed