| From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: GNU/Hurd portability patches |
| Date: | 2025-10-28 05:00:01 |
| Message-ID: | 9e9bacfa-37c6-48e9-9a25-741c79a1d5e5@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2025-10-28 05:28:55 | Re: COPY WHERE clause generated/system column reference |
| Previous Message | Peter Smith | 2025-10-28 04:26:17 | Re: Logical Replication of sequences |