From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Michael Banck <mbanck(at)gmx(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: GNU/Hurd portability patches |
Date: | 2025-09-24 15:37:51 |
Message-ID: | 3321785.1758728271@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> 24.09.2025 13:45, Michael Banck wrote:
>> 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...
We are currently doing a short pg_test_timing run in every BF run,
but with only a cursory regex-based sanity check on the output.
Since it's a TAP test, we could easily report the full output in
the TAP log without causing problems. I was already thinking about
doing that, and if there's some question about the minimum expected
timer resolution then it's really silly to not be capturing that
data.
I will go do that, and in a few day's time we should have enough
reports to see what we can realistically expect.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2025-09-24 15:49:11 | Re: "openssl" should not be optional |
Previous Message | Christoph Berg | 2025-09-24 15:13:44 | Re: "openssl" should not be optional |