Re: GNU/Hurd portability patches
От | Alexander Lakhin |
---|---|
Тема | Re: GNU/Hurd portability patches |
Дата | |
Msg-id | 766311fc-c075-47cf-92fb-4876c258f23c@gmail.com обсуждение исходный текст |
Ответ на | Re: GNU/Hurd portability patches (Michael Banck <mbanck@gmx.net>) |
Ответы |
Re: GNU/Hurd portability patches
|
Список | pgsql-hackers |
Hello Michael and Tom,
Thank you for spending time on this!
24.09.2025 13:45, Michael Banck wrote:
Thank you for spending time on this!
24.09.2025 13:45, Michael Banck wrote:
btw, the stats test failed in a similar way on hamerkop (Windows Server 2016) once, 35 days ago: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&dt=2025-08-19%2013%3A56%3A17
Yes, and all of such failures are counted at [1].
And we had discussed that (Windows-specific) anomaly too: [2]. Probably
something has changed in that environment, so that we see no such failures
for the last month.
How much timer resolution do we require from the system? GNU Mach seems to (at least try to) guarantee that the timer won't go backwards, but it does not guarantee (currently) that two consecutive clock_gettime() calls will return something different in all cases.
Regarding the lowest timer resolution, as I mentioned at [3], 32k_counter
gives only 0.030517 sec...
[1] https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#subscription.sql_sporadically_fails_on_hamerkop_due_to_zero_time_difference
[2] https://www.postgresql.org/message-id/CANhcyEX4hH9POyTM3vh%3D58newEF0%3DqgK46xF5i-RDir2zAZ4og%40mail.gmail.com
[3] https://www.postgresql.org/message-id/af1d252c-738f-46ab-99c6-a00e0d65aa04%40gmail.com
Best regards,
Alexander
В списке pgsql-hackers по дате отправления: