Re: GNU/Hurd portability patches

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