Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v1Q7j-008TVy-SV for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Sep 2025 14:05:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v1Q7i-00DTjs-G5 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Sep 2025 14:05:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v1Q7i-00DTjj-6B for pgsql-hackers@lists.postgresql.org; Wed, 24 Sep 2025 14:05:34 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v1Q7d-002dbo-00 for pgsql-hackers@lists.postgresql.org; Wed, 24 Sep 2025 14:05:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 58OE5Dde3312158; Wed, 24 Sep 2025 10:05:13 -0400 From: Tom Lane To: Michael Banck cc: Michael Paquier , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Thomas Munro Subject: Re: GNU/Hurd portability patches In-reply-to: <68d3a0a0.050a0220.167290.bcf3@mx.google.com> References: <6862e8d1.050a0220.194b8d.76fa@mx.google.com> <3245994.1751388110@sss.pgh.pa.us> <68643ea2.050a0220.128f53.3f77@mx.google.com> <2874644f-6431-41f4-abe2-99e5ab052606@gmail.com> <68d0f931.050a0220.3185e0.19ae@mx.google.com> <283c3d69-ef32-4391-9ea3-68e47c9dea31@gmail.com> <68d3a0a0.050a0220.167290.bcf3@mx.google.com> Comments: In-reply-to Michael Banck message dated "Wed, 24 Sep 2025 09:41:19 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3312156.1758722713.1@sss.pgh.pa.us> Date: Wed, 24 Sep 2025 10:05:13 -0400 Message-ID: <3312157.1758722713@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Banck 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