Content-Type: multipart/alternative;
 boundary="------------QcoMolds4m00wSOe1UYidRF8"
Message-ID: <766311fc-c075-47cf-92fb-4876c258f23c@gmail.com>
Date: Wed, 24 Sep 2025 18:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: GNU/Hurd portability patches
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>
References: <6862e8d1.050a0220.194b8d.76fa@mx.google.com>
 <3245994.1751388110@sss.pgh.pa.us>
 <68643ea2.050a0220.128f53.3f77@mx.google.com> <aGR04gPotq3SOaVo@paquier.xyz>
 <2874644f-6431-41f4-abe2-99e5ab052606@gmail.com>
 <aNB18ZFIXXv-FR6B@paquier.xyz> <68d0f931.050a0220.3185e0.19ae@mx.google.com>
 <283c3d69-ef32-4391-9ea3-68e47c9dea31@gmail.com>
 <aNMtzyqgin8I4r5H@paquier.xyz> <68d3a0a0.050a0220.167290.bcf3@mx.google.com>
 <68d3cbe8.5d0a0220.65f10.da5f@mx.google.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <68d3cbe8.5d0a0220.65f10.da5f@mx.google.com>
Archived-At: 
 <https://www.postgresql.org/message-id/766311fc-c075-47cf-92fb-4876c258f23c%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------QcoMolds4m00wSOe1UYidRF8
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
--------------QcoMolds4m00wSOe1UYidRF8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Michael and Tom,<br>
      <br>
      Thank you for spending time on this!<br>
      <br>
      24.09.2025 13:45, Michael Banck wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:68d3cbe8.5d0a0220.65f10.da5f@mx.google.com">
      <pre wrap="" class="moz-quote-pre">btw, the stats test failed in a similar way on hamerkop (Windows Server
2016) once, 35 days ago:
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&amp;dt=2025-08-19%2013%3A56%3A17">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hamerkop&amp;dt=2025-08-19%2013%3A56%3A17</a>
</pre>
    </blockquote>
    <br>
    Yes, and all of such failures are counted at [1].<br>
    And we had discussed that (Windows-specific) anomaly too: [2].
    Probably<br>
    something has changed in that environment, so that we see no such
    failures<br>
    for the last month.<br>
    <br>
    <span style="white-space: pre-wrap">
</span>
    <blockquote type="cite"
      cite="mid:68d3a0a0.050a0220.167290.bcf3@mx.google.com">
      <pre wrap="" class="moz-quote-pre">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.
</pre>
    </blockquote>
    <br>
    Regarding the lowest timer resolution, as I mentioned at [3],
    32k_counter<br>
    gives only 0.030517 sec...<br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#subscription.sql_sporadically_fails_on_hamerkop_due_to_zero_time_difference">https://wiki.postgresql.org/wiki/Known_Buildfarm_Test_Failures#subscription.sql_sporadically_fails_on_hamerkop_due_to_zero_time_difference</a><br>
    [2]
<a class="moz-txt-link-freetext" href="https://www.postgresql.org/message-id/CANhcyEX4hH9POyTM3vh%3D58newEF0%3DqgK46xF5i-RDir2zAZ4og%40mail.gmail.com">https://www.postgresql.org/message-id/CANhcyEX4hH9POyTM3vh%3D58newEF0%3DqgK46xF5i-RDir2zAZ4og%40mail.gmail.com</a><br>
    [3]
<a class="moz-txt-link-freetext" href="https://www.postgresql.org/message-id/af1d252c-738f-46ab-99c6-a00e0d65aa04%40gmail.com">https://www.postgresql.org/message-id/af1d252c-738f-46ab-99c6-a00e0d65aa04%40gmail.com</a><br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------QcoMolds4m00wSOe1UYidRF8--