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
