Content-Type: multipart/alternative;
 boundary="------------yYeu0wr11x64KWv77yuNWHwb"
Message-ID: <4557939c-01e1-47b6-8b79-bdfc74882275@gmail.com>
Date: Thu, 25 Sep 2025 08:00: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: <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>
 <3314741.1758724126@sss.pgh.pa.us>
 <68d413a3.a70a0220.24c74c.8be9@mx.google.com>
 <a1d9eab8-7063-4eb1-a922-f54923029c52@gmail.com>
 <68d460fe.170a0220.3c484.0a59@mx.google.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <68d460fe.170a0220.3c484.0a59@mx.google.com>
Archived-At: 
 <https://www.postgresql.org/message-id/4557939c-01e1-47b6-8b79-bdfc74882275%40gmail.com>
Precedence: bulk

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

Hello Michael,

25.09.2025 00:22, Michael Banck wrote:
> I ran that five times now without a problem, both with and without the
> Mach patch I mentioned earlier, and on 32 and 64 bit. Not sure what is
> going on here.

Maybe you're running it against REL_15_STABLE, where this test case is
absent... (I tested that on REL_18_STABLE.) I don't know what can prevent
the test case from failing if the underlying defect is still here.

> I saw those issues frequently on the initial 32bit Hurd VM I started to
> run the buildfarm code on, before I switched it to HPET timers. Since
> then, I don't think I saw that particular error again, but 4 out 1000 is
> not a lot of course.

There is also contrib/pg_stat_statements/entry_timestamp, which fails for
me when running in a loop:
for i in `seq 100`; do echo "ITERATION $i"; NO_TEMP_INSTALL=1 make -s check -C contrib/pg_stat_statements || break; done

on iterations 42, 60, 12, 5, 28:
ITERATION 28
...
ok 8         - wal                                        14 ms
not ok 9     - entry_timestamp                            14 ms
ok 10        - privileges                                 16 ms
...
1..15
# 1 of 15 tests failed.
# The differences that caused some tests to fail can be viewed in the file 
"/tst/postgresql/contrib/pg_stat_statements/regression.diffs".

$ cat contrib/pg_stat_statements/regression.diffs
diff -U3 /tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out 
/tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out
--- /tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out 2025-09-25 04:26:23.000000000 +0100
+++ /tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out 2025-09-25 04:50:43.000000000 +0100
@@ -147,7 +147,7 @@
  WHERE query LIKE '%STMTTS%';
   total | minmax_exec_zero | minmax_ts_after_ref | stats_since_after_ref
  -------+------------------+---------------------+-----------------------
-     2 |                1 |                   2 |                     0
+     2 |                2 |                   2 |                     0
  (1 row)

  -- Cleanup

Best regards,
Alexander
--------------yYeu0wr11x64KWv77yuNWHwb
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>
      25.09.2025 00:22, Michael Banck wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:68d460fe.170a0220.3c484.0a59@mx.google.com">
      <pre wrap="" class="moz-quote-pre">I ran that five times now without a problem, both with and without the
Mach patch I mentioned earlier, and on 32 and 64 bit. Not sure what is
going on here.</pre>
    </blockquote>
    <br>
    Maybe you're running it against REL_15_STABLE, where this test case
    is<br>
    absent... (I tested that on REL_18_STABLE.) I don't know what can
    prevent<br>
    the test case from failing if the underlying defect is still here.<br>
    <br>
    <blockquote type="cite"
      cite="mid:68d460fe.170a0220.3c484.0a59@mx.google.com">
      <pre wrap="" class="moz-quote-pre">I saw those issues frequently on the initial 32bit Hurd VM I started to
run the buildfarm code on, before I switched it to HPET timers. Since
then, I don't think I saw that particular error again, but 4 out 1000 is
not a lot of course.
</pre>
    </blockquote>
    <br>
    There is also contrib/pg_stat_statements/entry_timestamp, which
    fails for<br>
    me when running in a loop:<br>
    for i in `seq 100`; do echo "ITERATION $i"; NO_TEMP_INSTALL=1 make
    -s check -C contrib/pg_stat_statements || break; done<br>
    <br>
    on iterations 42, 60, 12, 5, 28:<br>
    ITERATION 28<br>
    ...<br>
    ok 8         - wal                                        14 ms<br>
    not ok 9     - entry_timestamp                            14 ms<br>
    ok 10        - privileges                                 16 ms<br>
    ...<br>
    1..15<br>
    # 1 of 15 tests failed.<br>
    # The differences that caused some tests to fail can be viewed in
    the file
    "/tst/postgresql/contrib/pg_stat_statements/regression.diffs".<br>
    <br>
    $ cat contrib/pg_stat_statements/regression.diffs<br>
    diff -U3
    /tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out
/tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out<br>
    ---
/tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out    
    2025-09-25 04:26:23.000000000 +0100<br>
    +++
/tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out     
    2025-09-25 04:50:43.000000000 +0100<br>
    @@ -147,7 +147,7 @@<br>
     WHERE query LIKE '%STMTTS%';<br>
      total | minmax_exec_zero | minmax_ts_after_ref |
    stats_since_after_ref <br>
 -------+------------------+---------------------+-----------------------<br>
    -     2 |                1 |                   2
    |                     0<br>
    +     2 |                2 |                   2
    |                     0<br>
     (1 row)<br>
     <br>
     -- Cleanup<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------yYeu0wr11x64KWv77yuNWHwb--