public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Lakhin <[email protected]>
To: Michael Banck <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: [email protected]
Cc: Thomas Munro <[email protected]>
Subject: Re: GNU/Hurd portability patches
Date: Mon, 22 Sep 2025 23:30:00 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
Attachments:
[text/x-csrc] tt.c (706B, ../[email protected]/3-tt.c)
download | inline:
#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;
}
view thread (50+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: GNU/Hurd portability patches
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox