Content-Type: multipart/alternative;
 boundary="------------IgVUfDRvYhsvKC4HuBgA1j23"
Message-ID: <a1d9eab8-7063-4eb1-a922-f54923029c52@gmail.com>
Date: Wed, 24 Sep 2025 23: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: Michael Paquier <michael@paquier.xyz>,
 pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
References: <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>
 <3314741.1758724126@sss.pgh.pa.us>
 <68d413a3.a70a0220.24c74c.8be9@mx.google.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <68d413a3.a70a0220.24c74c.8be9@mx.google.com>
Archived-At: 
 <https://www.postgresql.org/message-id/a1d9eab8-7063-4eb1-a922-f54923029c52%40gmail.com>
Precedence: bulk

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

24.09.2025 18:52, Michael Banck wrote:
> On Wed, Sep 24, 2025 at 10:28:46AM -0400, Tom Lane wrote:
>> It seems plausible that the execution time of the stats
>> test's function-under-test is so short that it sometimes
>> doesn't register as more than zero on a machine with poor
>> clock resolution.  It looks like that test only calls the
>> test function once or twice before checking that it's
>> accumulated some runtime, and the test function is nothing
>> more than
>>
>>      CREATE FUNCTION test_stat_func() RETURNS VOID LANGUAGE plpgsql AS $$BEGIN END;$$;
>>
>> I'd call this a bug in that test TBH.  It'd be saner to
>> make the function do something like pg_sleep for 1ms.
> I did that in the attached, so far my Hurd VM ran the stats test more
> than 1000 times without a failure with it. I have the loop running till
> 10000, I'll report back tomorrow.

If the stats test could be fixed this way, I wonder how to deal with
regress/subscription.sql. When running:
TESTS="$(printf "subscription %.0s" `seq 1000`)" make -s check-tests

on the same Hurd VM, I'm observing:
...
ok 986       - subscription                               53 ms
not ok 987   - subscription                               53 ms
ok 988       - subscription                               53 ms
...
# 4 of 1000 tests failed.
# The differences that caused some tests to fail can be viewed in the file 
"/home/demo/postgresql/src/test/regress/regression.diffs".

$ cat "/home/demo/postgresql/src/test/regress/regression.diffs"

--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:06:48.000000000 +0100
@@ -70,7 +70,7 @@
  SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
   ?column?
  ----------
- t
+ f
  (1 row)

  -- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out 
/home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:13.000000000 +0100
@@ -70,7 +70,7 @@
  SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
   ?column?
  ----------
- t
+ f
  (1 row)

  -- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out 
/home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:28.000000000 +0100
@@ -70,7 +70,7 @@
  SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
   ?column?
  ----------
- t
+ f
  (1 row)

  -- fail - name already exists
diff -U3 /home/demo/postgresql/src/test/regress/expected/subscription.out 
/home/demo/postgresql/src/test/regress/results/subscription.out
--- /home/demo/postgresql/src/test/regress/expected/subscription.out 2025-09-24 19:49:53.000000000 +0100
+++ /home/demo/postgresql/src/test/regress/results/subscription.out 2025-09-24 20:07:33.000000000 +0100
@@ -70,7 +70,7 @@
  SELECT :'prev_stats_reset' < stats_reset FROM pg_stat_subscription_stats WHERE subname = 'regress_testsub';
   ?column?
  ----------
- t
+ f
  (1 row)

  -- fail - name already exists


Best regards,
Alexander
--------------IgVUfDRvYhsvKC4HuBgA1j23
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">24.09.2025 18:52, Michael Banck wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:68d413a3.a70a0220.24c74c.8be9@mx.google.com">
      <pre wrap="" class="moz-quote-pre">On Wed, Sep 24, 2025 at 10:28:46AM -0400, Tom Lane wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">It seems plausible that the execution time of the stats
test's function-under-test is so short that it sometimes
doesn't register as more than zero on a machine with poor
clock resolution.  It looks like that test only calls the
test function once or twice before checking that it's
accumulated some runtime, and the test function is nothing
more than

    CREATE FUNCTION test_stat_func() RETURNS VOID LANGUAGE plpgsql AS $$BEGIN END;$$;

I'd call this a bug in that test TBH.  It'd be saner to
make the function do something like pg_sleep for 1ms.
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
I did that in the attached, so far my Hurd VM ran the stats test more
than 1000 times without a failure with it. I have the loop running till
10000, I'll report back tomorrow.
</pre>
    </blockquote>
    <br>
    If the stats test could be fixed this way, I wonder how to deal with<br>
    regress/subscription.sql. When running:<br>
    TESTS="$(printf "subscription %.0s" `seq 1000`)" make -s check-tests<br>
    <br>
    on the same Hurd VM, I'm observing:<br>
    ...<br>
    ok 986       - subscription                               53 ms<br>
    not ok 987   - subscription                               53 ms<br>
    ok 988       - subscription                               53 ms<br>
    ...<br>
    # 4 of 1000 tests failed.<br>
    # The differences that caused some tests to fail can be viewed in
    the file "/home/demo/postgresql/src/test/regress/regression.diffs".<br>
    <br>
    $ cat "/home/demo/postgresql/src/test/regress/regression.diffs"<br>
    <br>
    ---
    /home/demo/postgresql/src/test/regress/expected/subscription.out   
    2025-09-24 19:49:53.000000000 +0100<br>
    +++
    /home/demo/postgresql/src/test/regress/results/subscription.out    
    2025-09-24 20:06:48.000000000 +0100<br>
    @@ -70,7 +70,7 @@<br>
     SELECT :'prev_stats_reset' &lt; stats_reset FROM
    pg_stat_subscription_stats WHERE subname = 'regress_testsub';<br>
      ?column? <br>
     ----------<br>
    - t<br>
    + f<br>
     (1 row)<br>
     <br>
     -- fail - name already exists<br>
    diff -U3
    /home/demo/postgresql/src/test/regress/expected/subscription.out
    /home/demo/postgresql/src/test/regress/results/subscription.out<br>
    ---
    /home/demo/postgresql/src/test/regress/expected/subscription.out   
    2025-09-24 19:49:53.000000000 +0100<br>
    +++
    /home/demo/postgresql/src/test/regress/results/subscription.out    
    2025-09-24 20:07:13.000000000 +0100<br>
    @@ -70,7 +70,7 @@<br>
     SELECT :'prev_stats_reset' &lt; stats_reset FROM
    pg_stat_subscription_stats WHERE subname = 'regress_testsub';<br>
      ?column? <br>
     ----------<br>
    - t<br>
    + f<br>
     (1 row)<br>
     <br>
     -- fail - name already exists<br>
    diff -U3
    /home/demo/postgresql/src/test/regress/expected/subscription.out
    /home/demo/postgresql/src/test/regress/results/subscription.out<br>
    ---
    /home/demo/postgresql/src/test/regress/expected/subscription.out   
    2025-09-24 19:49:53.000000000 +0100<br>
    +++
    /home/demo/postgresql/src/test/regress/results/subscription.out    
    2025-09-24 20:07:28.000000000 +0100<br>
    @@ -70,7 +70,7 @@<br>
     SELECT :'prev_stats_reset' &lt; stats_reset FROM
    pg_stat_subscription_stats WHERE subname = 'regress_testsub';<br>
      ?column? <br>
     ----------<br>
    - t<br>
    + f<br>
     (1 row)<br>
     <br>
     -- fail - name already exists<br>
    diff -U3
    /home/demo/postgresql/src/test/regress/expected/subscription.out
    /home/demo/postgresql/src/test/regress/results/subscription.out<br>
    ---
    /home/demo/postgresql/src/test/regress/expected/subscription.out   
    2025-09-24 19:49:53.000000000 +0100<br>
    +++
    /home/demo/postgresql/src/test/regress/results/subscription.out    
    2025-09-24 20:07:33.000000000 +0100<br>
    @@ -70,7 +70,7 @@<br>
     SELECT :'prev_stats_reset' &lt; stats_reset FROM
    pg_stat_subscription_stats WHERE subname = 'regress_testsub';<br>
      ?column? <br>
     ----------<br>
    - t<br>
    + f<br>
     (1 row)<br>
     <br>
     -- fail - name already exists<br>
    <br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------IgVUfDRvYhsvKC4HuBgA1j23--