Message-ID: <9e9bacfa-37c6-48e9-9a25-741c79a1d5e5@gmail.com>
Date: Tue, 28 Oct 2025 07:00:01 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: GNU/Hurd portability patches
From: Alexander Lakhin <exclusion@gmail.com>
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>
 <4557939c-01e1-47b6-8b79-bdfc74882275@gmail.com>
Content-Language: en-US
In-Reply-To: <4557939c-01e1-47b6-8b79-bdfc74882275@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/9e9bacfa-37c6-48e9-9a25-741c79a1d5e5%40gmail.com>
Precedence: bulk

Hello Michael,

25.09.2025 08:00, Alexander Lakhin wrote:
>
>> 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.

One month later, fruitcrow has generated this failure too:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-10-25%2007%3A45%3A03

pgsql.build/contrib/pg_stat_statements/regression.diffs
diff -U3 
/home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out 
/home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out
--- /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out 
2025-10-25 08:45:03.000000000 +0100
+++ /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out 
2025-10-25 08:57:31.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

Thus, the "zero time difference" issue in general still exists.

Best regards,
Alexander