One-off failure in "cluster" test
От | Thomas Munro |
---|---|
Тема | One-off failure in "cluster" test |
Дата | |
Msg-id | CA+hUKGLTK6ZuEkpeJ05-MEmvmgZveCh+_w013m7+yKWFSmRcDA@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: One-off failure in "cluster" test
|
Список | pgsql-hackers |
Hi, I wonder what caused this[1] one-off failure to see tuples in clustered order: diff -U3 /home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/expected/cluster.out /home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/results/cluster.out --- /home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/expected/cluster.out 2020-06-11 07:58:23.738084255 +0300 +++ /home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/results/cluster.out 2020-07-05 02:35:06.396023210 +0300 @@ -462,7 +462,8 @@ where row(hundred, thousand, tenthous) <= row(lhundred, lthousand, ltenthous); hundred | lhundred | thousand | lthousand | tenthous | ltenthous ---------+----------+----------+-----------+----------+----------- -(0 rows) + 0 | 99 | 0 | 999 | 0 | 9999 +(1 row) I guess a synchronised scan could cause that, but I wouldn't expect one here. [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2020-07-04%2023:10:22
В списке pgsql-hackers по дате отправления: