Horton
Menu

Re: GNU/Hurd portability patches

Tom Lane <tgl@sss.pgh.pa.us>

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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add minimal sleep to stats isolation test functions.

  2. Include pg_test_timing's full output in the TAP test log.

  3. Make sure IOV_MAX is defined.

  4. Make safeguard against incorrect flags for fsync more portable.