Horton

Re: GNU/Hurd portability patches

Alexander Lakhin <exclusion@gmail.com>

View thread
From: Alexander Lakhin <exclusion@gmail.com>
To: Michael Banck <mbanck@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-09-24T15:00:00Z
Lists: pgsql-hackers 
Hello Michael and Tom,

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