Re: GNU/Hurd portability patches

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: GNU/Hurd portability patches
Дата
Msg-id 283c3d69-ef32-4391-9ea3-68e47c9dea31@gmail.com
обсуждение исходный текст
Ответ на Re: GNU/Hurd portability patches  (Michael Banck <mbanck@gmx.net>)
Ответы Re: GNU/Hurd portability patches
Re: GNU/Hurd portability patches
Список pgsql-hackers
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
Вложения

В списке pgsql-hackers по дате отправления: