Re: GNU/Hurd portability patches - Mailing list pgsql-hackers
From | Michael Banck |
---|---|
Subject | Re: GNU/Hurd portability patches |
Date | |
Msg-id | 68d0f931.050a0220.3185e0.19ae@mx.google.com Whole thread Raw |
In response to | Re: GNU/Hurd portability patches (Michael Paquier <michael@paquier.xyz>) |
Responses |
Re: GNU/Hurd portability patches
|
List | pgsql-hackers |
On Mon, Sep 22, 2025 at 07:02:25AM +0900, Michael Paquier wrote: > On Sun, Sep 21, 2025 at 09:00:00AM +0300, Alexander Lakhin wrote: > > So it seems to me that Hurd is not mature enough yet to test Postgres. > > I'd say that it is likely not mature enough for production. In terms > of testing, that seems kind of OK. Ack. > 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 PG15: |test multiple-row-versions ... FAILED (test process exited with exit code 1) 145260 ms This one is a segfault, it happened twice so far and only on REL_15_STABLE: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-09-18%2007%3A57%3A40 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-09-03%2007%3A36%3A45 |setup failed: server closed the connection unexpectedly | This probably means the server terminated abnormally | before or while processing the request. |/hurd/crash: [...]/buildroot/REL_15_STABLE/inst/bin/postgres -D data-C(25142) crashed, signal {no:11, code:2, error:2},exception {1, code:2, subcode:0}, PCs: { | 0x1019b4d34 0x1028ee2a0 0x10249e1ac 0x1025da71f 0x102596611 0x10049fe63, | 0x102497aec 0x1028e674e 0x1024ada52 0x1024aeb2a 0x1024a785b 0x10291f5b7 0x10291f | 625 0x1024c7242 0x1024986a2 0x1024c72c0, | 0x102497aec 0x102572ace | }, killing task 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 Michael
pgsql-hackers by date: