On Wed, Jul 31, 2024 at 02:00:00PM +0300, Alexander Lakhin wrote:
> --- /home/nm/farm/gcc64/REL_14_STABLE/pgsql.build/src/test/regress/expected/stats.out 2022-03-30 01:18:17.000000000
+0000
> +++ /home/nm/farm/gcc64/REL_14_STABLE/pgsql.build/src/test/regress/results/stats.out 2024-07-30 09:49:39.000000000
+0000
> @@ -165,11 +165,11 @@
> WHERE relname like 'trunc_stats_test%' order by relname;
> relname | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup
> -------------------+-----------+-----------+-----------+------------+------------
> - trunc_stats_test | 3 | 0 | 0 | 0 | 0
> - trunc_stats_test1 | 4 | 2 | 1 | 1 | 0
> - trunc_stats_test2 | 1 | 0 | 0 | 1 | 0
> - trunc_stats_test3 | 4 | 0 | 0 | 2 | 2
> - trunc_stats_test4 | 2 | 0 | 0 | 0 | 2
> + trunc_stats_test | 0 | 0 | 0 | 0 | 0
> + trunc_stats_test1 | 0 | 0 | 0 | 0 | 0
> + trunc_stats_test2 | 0 | 0 | 0 | 0 | 0
> + trunc_stats_test3 | 0 | 0 | 0 | 0 | 0
> + trunc_stats_test4 | 0 | 0 | 0 | 0 | 0
> ...
>
> inst/logfile contains:
> 2024-07-30 09:25:11.225 UTC [63307946:1] LOG: using stale statistics
> instead of current ones because stats collector is not responding
> 2024-07-30 09:25:11.345 UTC [11206724:559] pg_regress/create_index LOG:
> using stale statistics instead of current ones because stats collector is
> not responding
> ...
> I could not find such failures coming from POWER8 animals: hoverfly
> (running AIX 7200-04-03-2038), ayu, boa, chub, and I did not encounter such
> anomalies on x86 nor ARM platforms.
The animals you list as affected share a filesystem. The failure arises from
the slow filesystem metadata operations of that filesystem.
> Thus, it looks like this stats collector issue is only happening on this
> concrete platform, and given [11], I think such failures perhaps should
> be just ignored for the next two years (until v14 EOL) unless AIX 7.1
> will be upgraded and we see them on a vendor-supported OS version.
This has happened on non-POWER, I/O-constrained machines. Still, I have been
ignoring these failures. The stats subsystem was designed to drop stats
updates at times, which was always at odds with the need for stable tests. So
the failures witness a defect of the test, not a defect of the backend.
Stabilizing this test was a known benefit of the new stats implementation.
