Hello,
Michael Banck via Bug reports for the GNU Hurd, le mer. 24 sept. 2025 08:41:51
+0200, a ecrit:
> not sure whether this is the same issue or something related, but
It's probably related.
> On Sun, Sep 21, 2025 at 09:14:04AM +0000, Damien Zammit wrote:
> > Between reading mtime and reading hpclock_read_counter,
> > there may be an interrupt that updates mtime, therefore
> > we need a check to perform the clock read process again
> > in this case.
> >
> > TESTED: on UP using:
>
> There is a PostgreSQL isolation test that seems to be triggered by
> the clock, while not moving backwards, not moving forward, i.e.
> reporting the same timestamp twice in a row on subsequent
> clock_gettime() calls.
>
> If I run the test case from [1] like this, I get, even with this patch
> applied after a few thousand iterations:
>
> |$ for i in {1..10000}; do printf "ITERATION $i "; ./tt 100 || break; done
> [...]
> | ITERATION 3029 t1: -2073074700, t2: -2073069580, t2 - t1: 5120 (r: 4950)
> | ITERATION 3030 t1: -2070257921, t2: -2070257921, t2 - t1: 0 (r: 4950)
Yes, that can still happen with the current implementation: we really
advance the time on clock tick, and use the hpet only to interpolate
the time between the ticks. If for whatever reason the clock and the
hpet are not perfectly synchronized, we clamp the advance so that the
reported time stays monotonic. So two consecutive calls may report the
same value. Trying to make sure that time always progress at least by
1ns (or 1µs if the application is using gettimeofday...) would be quite
involved.
I'd tend to say this is an issue in postgresql: it shouldn't assume that
clocks have infinite precision.
Samuel
