Re: GNU/Hurd portability patches

Hi,

On Mon, Sep 22, 2025 at 11:30:00PM +0300, Alexander Lakhin wrote:
> 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.

Or, for that matter, to improve GNU Mach/Hurd...
 
> 22.09.2025 10:22, Michael Banck wrote:
> > 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.

Thanks for the test. I ran the stats test with the GNU Mach patch and
while it seemed to help, it did error out eventually. However, your test
case is much better/faster and I also see 0 deltas after a few hundred
to a few thousand iterations.

I'll report that on their development list, looks like they have not
plugged all the holes yet..


Michael