Re: GNU/Hurd portability patches
| От | Alexander Lakhin | 
|---|---|
| Тема | Re: GNU/Hurd portability patches | 
| Дата | |
| Msg-id | 9e9bacfa-37c6-48e9-9a25-741c79a1d5e5@gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: GNU/Hurd portability patches (Alexander Lakhin <exclusion@gmail.com>) | 
| Ответы | 
                	
            		Re: GNU/Hurd portability patches
            		
            		 | 
		
| Список | pgsql-hackers | 
Hello Michael, 25.09.2025 08:00, Alexander Lakhin wrote: > >> 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. One month later, fruitcrow has generated this failure too: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fruitcrow&dt=2025-10-25%2007%3A45%3A03 pgsql.build/contrib/pg_stat_statements/regression.diffs diff -U3 /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out --- /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/expected/entry_timestamp.out 2025-10-25 08:45:03.000000000 +0100 +++ /home/demo/client-code-REL_19_1/buildroot/HEAD/pgsql.build/contrib/pg_stat_statements/results/entry_timestamp.out 2025-10-25 08:57:31.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 Thus, the "zero time difference" issue in general still exists. Best regards, Alexander
В списке pgsql-hackers по дате отправления: