Re: 15beta1 test failure on mips in isolation/expected/stats
От | Tom Lane |
---|---|
Тема | Re: 15beta1 test failure on mips in isolation/expected/stats |
Дата | |
Msg-id | 250690.1653010951@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 15beta1 test failure on mips in isolation/expected/stats (Christoph Berg <myon@debian.org>) |
Ответы |
Re: 15beta1 test failure on mips in isolation/expected/stats
Re: 15beta1 test failure on mips in isolation/expected/stats |
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: