Hi,
not sure whether this is the same issue or something related, but
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)
This test seems to run much faster than the one from the commit message,
it takes 2.5s for 1000 iterations on my VM (but I need to set the loop
to 10000 in order to reliably reproduce it).
Michael
[1] https://www.postgresql.org/message-id/attachment/181932/tt.c
