Re: GNU/Hurd portability patches
Alexander Lakhin <exclusion@gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
To: Michael Banck <mbanck@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>,
pgsql-hackers@lists.postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-09-25T05:00:00Z
Lists: pgsql-hackers
Hello Michael, 25.09.2025 00:22, Michael Banck wrote: > I ran that five times now without a problem, both with and without the > Mach patch I mentioned earlier, and on 32 and 64 bit. Not sure what is > going on here. Maybe you're running it against REL_15_STABLE, where this test case is absent... (I tested that on REL_18_STABLE.) I don't know what can prevent the test case from failing if the underlying defect is still here. > I saw those issues frequently on the initial 32bit Hurd VM I started to > run the buildfarm code on, before I switched it to HPET timers. Since > then, I don't think I saw that particular error again, but 4 out 1000 is > not a lot of course. There is also contrib/pg_stat_statements/entry_timestamp, which fails for me when running in a loop: for i in `seq 100`; do echo "ITERATION $i"; NO_TEMP_INSTALL=1 make -s check -C contrib/pg_stat_statements || break; done on iterations 42, 60, 12, 5, 28: ITERATION 28 ... ok 8 - wal 14 ms not ok 9 - entry_timestamp 14 ms ok 10 - privileges 16 ms ... 1..15 # 1 of 15 tests failed. # The differences that caused some tests to fail can be viewed in the file "/tst/postgresql/contrib/pg_stat_statements/regression.diffs". $ cat contrib/pg_stat_statements/regression.diffs diff -U3 /tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out /tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out --- /tst/postgresql/contrib/pg_stat_statements/expected/entry_timestamp.out 2025-09-25 04:26:23.000000000 +0100 +++ /tst/postgresql/contrib/pg_stat_statements/results/entry_timestamp.out 2025-09-25 04:50:43.000000000 +0100 @@ -147,7 +147,7 @@ WHERE query LIKE '%STMTTS%'; total | minmax_exec_zero | minmax_ts_after_ref | stats_since_after_ref -------+------------------+---------------------+----------------------- - 2 | 1 | 2 | 0 + 2 | 2 | 2 | 0 (1 row) -- Cleanup Best regards, Alexander