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: Michael Banck <mbanck@gmx.net>
Cc: Michael Paquier <michael@paquier.xyz>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-09-24T14:05:13Z
Lists: pgsql-hackers 
Michael Banck <mbanck@gmx.net> writes:
> 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.

I think it is reasonable to require the clock to not go backwards
during a test run, but it's not at all reasonable to require the
clock to advance by more than zero between two successive readings.

We used to encounter the no-advance case all the time, back when
machines had clock resolutions measured in milliseconds.  It's
relatively rare now though, so it's possible that some test case
has crept in that expects that.  But I'd call it a bug in the
test case if so.

It'd be interesting to see the output of a pg_test_timing run
from your Hurd machine.

			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.