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:
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#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#define PG_INSTR_CLOCK CLOCK_MONOTONIC
#define NS_PER_S 1000000000L
static inline long int
pg_clock_gettime_ns(void)
{
long int now;
struct timespec tmp;
clock_gettime(PG_INSTR_CLOCK, &tmp);
now = tmp.tv_sec * NS_PER_S + tmp.tv_nsec;
return now;
}
int main(int argc, char *argv[])
{
long int t1, t2;
long int r = 0;
int n = (argc > 1) ? atol(argv[1]) : 0;
t1 = pg_clock_gettime_ns();
for (long int i = 0; i < n; i++) r += i;
t2 = pg_clock_gettime_ns();
printf("t1: %ld, t2: %ld, t2 - t1: %ld (r: %ld)\n ", t1, t2, t2 - t1, r);
if (t2 - t1 == 0) return 1;
return 0;
}
