Hello Kuroda-san,
20.07.2025 11:00, Alexander Lakhin wrote:
Yeah, I made a simple test for GetSystemTimePreciseAsFileTime() and
confirmed that in my VM it provides sub-microsecond precision. Regarding
NTP, I think the second failure of this ilk [1] makes this cause close to
impossible. (Can't wait for the third one to gather more information.)
And here it is [1]:
diff --strip-trailing-cr -U3 c:/build-farm-local/buildroot/HEAD/pgsql/src/test/isolation/expected/stats.out
c:/build-farm-local/buildroot/HEAD/pgsql.build/testrun/isolation/isolation/results/stats.out
---
c:/build-farm-local/buildroot/HEAD/pgsql/src/test/isolation/expected/stats.out
2025-07-22 20:08:30 +0900
+++
c:/build-farm-local/buildroot/HEAD/pgsql.build/testrun/isolation/isolation/results/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.
There was the same looking failure on caiman, which is running on
continuously updated Fedora: [2].
I could not reproduce that one either, but suspected the OS kernel:
It had 6.14.0-0.rc3.20250219git6537cfb395f3.31.fc43.x86_64 at the moment
of the failure and updated to 6.14.0-0.rc4.36.fc43.x86_64 on 2025-02-27.
There was no failures of this kind since then.
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)...
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2025-07-22%2011%3A02%3A15
[2]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=caiman&dt=2025-02-23%2006%3A54%3A54
Best regards,
Alexander
