Re: 15beta1 test failure on mips in isolation/expected/stats

At Thu, 19 May 2022 21:42:31 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Christoph Berg <myon@debian.org> writes:
> > Debian unstable mips (the old 32-bit one):
> 
> > --- /<<PKGBUILDDIR>>/src/test/isolation/expected/stats.out    2022-05-16 21:10:42.000000000 +0000
> > +++ /<<PKGBUILDDIR>>/build/src/test/isolation/output_iso/results/stats.out    2022-05-18 23:26:56.573000536 +0000
> > @@ -2854,7 +2854,7 @@
> 
> >  seq_scan|seq_tup_read|n_tup_ins|n_tup_upd|n_tup_del|n_live_tup|n_dead_tup|vacuum_count
> >  --------+------------+---------+---------+---------+----------+----------+------------
> > -       3|           9|        5|        1|        0|         1|         1|           0
> > +       3|           9|        5|        1|        0|         4|         1|           0
> >  (1 row)
> 
> I have just discovered that I can reproduce this identical symptom
> fairly repeatably on an experimental lashup that I've been running
> with bleeding-edge NetBSD on my ancient HPPA box.  (You didn't think
> I was just going to walk away from that hardware, did you?)
> 
> Even more interesting, the repeatability varies with the settings
> of max_connections and max_prepared_transactions.  At low values
> (resp. 20 and 0) I've not been able to make it happen at all, but
> at 100 and 2 it happens circa three times out of four.
> 
> I have no idea where to start looking, but this is clearly an issue
> in the new stats code ... or else the hoped-for goal of removing
> flakiness from the stats tests is just as far away as ever.

Doesn't the step s1_table_stats needs a blocking condition (s2_ff)?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center