Content-Type: multipart/mixed; boundary="------------BN4ENl4hSifYkoa9ohKP6kxx"
Message-ID: <283c3d69-ef32-4391-9ea3-68e47c9dea31@gmail.com>
Date: Mon, 22 Sep 2025 23:30:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: GNU/Hurd portability patches
To: Michael Banck <mbanck@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
 pgsql-hackers@lists.postgresql.org, 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>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <68d0f931.050a0220.3185e0.19ae@mx.google.com>
Archived-At: 
 <https://www.postgresql.org/message-id/283c3d69-ef32-4391-9ea3-68e47c9dea31%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------BN4ENl4hSifYkoa9ohKP6kxx
Content-Type: multipart/alternative;
 boundary="------------8mk6nGah06Ka7BP84dIWAtgp"

--------------8mk6nGah06Ka7BP84dIWAtgp
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Michael,

Thank you for paying attention to this!

Maybe I was wrong and we can at least categorize these failures -- I hope
their number is finite, but my point was that it's hardly possible to use
the information, that fruitcrow gives us, to improve Postgres.

22.09.2025 10:22, Michael Banck wrote:
> On Mon, Sep 22, 2025 at 07:02:25AM +0900, Michael Paquier wrote:
>
>> However, failures like the one you are reporting here bring noise in
>> the buildfarm, meaning that we would perhaps tend to ignore reports
>> that are in fact legit because we don't really know what would be
>> Hurd-related or Postgres-related.
> I will keep an eye on it.
>
> There have been two (infrequent) failures in the isoloation tests as
> well, which I haven't had time to investigate further:
>
>
> In PG17:
>
> |not ok 98    - stats                                    2100 ms
>
> |diff -U3 buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/expected/stats_1.out buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/output_iso/results/stats.out
> |--- buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/expected/stats_1.out	2025-09-15 22:06:24.000000000 +0100
> |+++ buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/output_iso/results/stats.out	2025-09-15 22:23:05.000000000 +0100
> |@@ -1445,7 +1445,7 @@
> |
> | name          |pg_stat_get_function_calls|total_above_zero|self_above_zero
> | --------------+--------------------------+----------------+---------------
> |-test_stat_func|                         1|t               |t
> |+test_stat_func|                         1|f               |f
> | (1 row)
>
> This one happened twice as well, and so far only on REL_17_STABLE:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-09-15%2021%3A06%3A17
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-09-13%2008%3A04%3A05
>
> This might be due to the HPET timer not always being monotonic - there
> has been an independent report via the Debian autobuilder and a GNU Mach
> fix was committed last night, I'll check whether this can be
> reproduced/confirmed-fixed with this change:
>
> https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00020.html
> https://salsa.debian.org/hurd-team/gnumach/-/commit/06079a8d212817ee0365f318bd90b67bf56bfb06

I reproduced the issue locally and found that
         /* total elapsed time in this function call */
         INSTR_TIME_SET_CURRENT(total);
         INSTR_TIME_SUBTRACT(total, fcu->start);
sometimes gives total.ticks = 0.

I tried the test program from [2] and got on my VM:
went backwards 0 out of 10000000 times
(three times)

But I've created my own test program (see attached), which shows:
for i in {1..1000}; do printf "ITERATION $i "; ./tt 100 || break; done
  ITERATION 1 t1: 55873639081080, t2: 55873639084090, t2 - t1: 3010 (r: 4950)
  ITERATION 2 t1: 55873641019440, t2: 55873641025700, t2 - t1: 6260 (r: 4950)
  ITERATION 3 t1: 55873642794200, t2: 55873642797130, t2 - t1: 2930 (r: 4950)
...
  ITERATION 23 t1: 55873675001590, t2: 55873675001590, t2 - t1: 0 (r: 4950)

I don't know how to test the patch committed, but if you can, that would
be nice.

Best regards,
Alexander
--------------8mk6nGah06Ka7BP84dIWAtgp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Michael,<br>
      <br>
      Thank you for paying attention to this!<br>
      <br>
      Maybe I was wrong and we can at least categorize these failures --
      I hope<br>
      their number is finite, but my point was that it's hardly possible
      to use<br>
      the information, that fruitcrow gives us, to improve Postgres.<br>
      <br>
      22.09.2025 10:22, Michael Banck wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:68d0f931.050a0220.3185e0.19ae@mx.google.com">
      <pre wrap="" class="moz-quote-pre">On Mon, Sep 22, 2025 at 07:02:25AM +0900, Michael Paquier wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">However, failures like the one you are reporting here bring noise in
the buildfarm, meaning that we would perhaps tend to ignore reports
that are in fact legit because we don't really know what would be
Hurd-related or Postgres-related. 
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I will keep an eye on it.

There have been two (infrequent) failures in the isoloation tests as
well, which I haven't had time to investigate further:


In PG17:

|not ok 98    - stats                                    2100 ms

|diff -U3 buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/expected/stats_1.out buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/output_iso/results/stats.out
|--- buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/expected/stats_1.out	2025-09-15 22:06:24.000000000 +0100
|+++ buildroot/REL_17_STABLE/pgsql.build/src/test/isolation/output_iso/results/stats.out	2025-09-15 22:23:05.000000000 +0100
|@@ -1445,7 +1445,7 @@
| 
| name          |pg_stat_get_function_calls|total_above_zero|self_above_zero
| --------------+--------------------------+----------------+---------------
|-test_stat_func|                         1|t               |t              
|+test_stat_func|                         1|f               |f              
| (1 row)

This one happened twice as well, and so far only on REL_17_STABLE:

<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&amp;dt=2025-09-15%2021%3A06%3A17">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&amp;dt=2025-09-15%2021%3A06%3A17</a>
<a class="moz-txt-link-freetext" href="https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&amp;dt=2025-09-13%2008%3A04%3A05">https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&amp;dt=2025-09-13%2008%3A04%3A05</a>

This might be due to the HPET timer not always being monotonic - there
has been an independent report via the Debian autobuilder and a GNU Mach
fix was committed last night, I'll check whether this can be
reproduced/confirmed-fixed with this change:

<a class="moz-txt-link-freetext" href="https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00020.html">https://lists.gnu.org/archive/html/bug-hurd/2025-09/msg00020.html</a>
<a class="moz-txt-link-freetext" href="https://salsa.debian.org/hurd-team/gnumach/-/commit/06079a8d212817ee0365f318bd90b67bf56bfb06">https://salsa.debian.org/hurd-team/gnumach/-/commit/06079a8d212817ee0365f318bd90b67bf56bfb06</a>
</pre>
    </blockquote>
    <br>
    I reproduced the issue locally and found that <br>
            /* total elapsed time in this function call */<br>
            INSTR_TIME_SET_CURRENT(total);<br>
            INSTR_TIME_SUBTRACT(total, fcu-&gt;start);<br>
    sometimes gives total.ticks = 0.<br>
    <br>
    I tried the test program from [2] and got on my VM:<br>
    went backwards 0 out of 10000000 times<br>
    (three times)<br>
    <br>
    But I've created my own test program (see attached), which shows:<br>
    for i in {1..1000}; do printf "ITERATION $i "; ./tt 100 || break;
    done<br>
     ITERATION 1 t1: 55873639081080, t2: 55873639084090, t2 - t1: 3010
    (r: 4950)<br>
     ITERATION 2 t1: 55873641019440, t2: 55873641025700, t2 - t1: 6260
    (r: 4950)<br>
     ITERATION 3 t1: 55873642794200, t2: 55873642797130, t2 - t1: 2930
    (r: 4950)<br>
    ... <br>
     ITERATION 23 t1: 55873675001590, t2: 55873675001590, t2 - t1: 0 (r:
    4950)<br>
    <br>
    I don't know how to test the patch committed, but if you can, that
    would<br>
    be nice.<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------8mk6nGah06Ka7BP84dIWAtgp--

--------------BN4ENl4hSifYkoa9ohKP6kxx
Content-Type: text/x-csrc; charset=UTF-8; name="tt.c"
Content-Disposition: attachment; filename="tt.c"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPHRpbWUuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIu
aD4KCiNkZWZpbmUgUEdfSU5TVFJfQ0xPQ0sgIENMT0NLX01PTk9UT05JQwojZGVmaW5lIE5T
X1BFUl9TICAgMTAwMDAwMDAwMEwKCnN0YXRpYyBpbmxpbmUgbG9uZyBpbnQKcGdfY2xvY2tf
Z2V0dGltZV9ucyh2b2lkKQp7CiAgICBsb25nIGludCAgICAgIG5vdzsKICAgIHN0cnVjdCB0
aW1lc3BlYyB0bXA7CgogICAgY2xvY2tfZ2V0dGltZShQR19JTlNUUl9DTE9DSywgJnRtcCk7
CiAgICBub3cgPSB0bXAudHZfc2VjICogTlNfUEVSX1MgKyB0bXAudHZfbnNlYzsKICAgIHJl
dHVybiBub3c7Cn0KCmludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCnsKICAgICBs
b25nIGludCB0MSwgdDI7CiAgICAgbG9uZyBpbnQgciA9IDA7CiAgICAgaW50IG4gPSAoYXJn
YyA+IDEpID8gYXRvbChhcmd2WzFdKSA6IDA7CgogICAgIHQxID0gcGdfY2xvY2tfZ2V0dGlt
ZV9ucygpOwoKICAgICBmb3IgKGxvbmcgaW50IGkgPSAwOyBpIDwgbjsgaSsrKSByICs9IGk7
CgogICAgIHQyID0gcGdfY2xvY2tfZ2V0dGltZV9ucygpOwoKICAgICBwcmludGYoInQxOiAl
bGQsIHQyOiAlbGQsIHQyIC0gdDE6ICVsZCAocjogJWxkKVxuICIsIHQxLCB0MiwgdDIgLSB0
MSwgcik7CgogICAgIGlmICh0MiAtIHQxID09IDApIHJldHVybiAxOwogICAgIHJldHVybiAw
Owp9Cg==

--------------BN4ENl4hSifYkoa9ohKP6kxx--