RE: stats.sql might fail due to shared buffers also used by parallel tests

Dear Alexander,

> And here it is [1]:
> diff --strip-trailing-cr -U3
> c:/build-farm-local/buildroot/HEAD/pgsql/src/test/isolation/expected/stats.ou
> t
> c:/build-farm-local/buildroot/HEAD/pgsql.build/testrun/isolation/isolation/res
> ults/stats.out
> ---
> c:/build-farm-local/buildroot/HEAD/pgsql/src/test/isolation/expected/stats.ou
> t 2025-07-22 20:08:30 +0900
> +++
> c:/build-farm-local/buildroot/HEAD/pgsql.build/testrun/isolation/isolation/res
> ults/stats.out 2025-07-22 20:30:47 +0900
> @@ -3729,7 +3729,7 @@
> 
>   name |pg_stat_get_function_calls|total_above_zero|self_above_zero
>   --------------+--------------------------+----------------+---------------
> -test_stat_func|                         1|t |t
> +test_stat_func|                         1|f |f
>   (1 row)
> 
> Not related to subscriptions this time, but still related to pg_stat and
> time measurement.

It looks like for me that we measured the execution time of the function in
millisecond but it was "zero", right?

> So I think we could observe such anomalies if, say, the OS kernel can't
> read system clock in time (stalls for a millisecond when accessing it)...

I also feel like that. But if so, how should we fix tests? We must remove all
stuff which assumes the time is monotonic?

Best regards,
Hayato Kuroda
FUJITSU LIMITED