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:
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 по дате отправления: