Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Fri, 2026-10-02 at 22:36 +0000, PG Bug reporting form wrote:
>> SELECT uuidv7(
>> (timestamptz '1970-01-01 UTC'
>> + interval '281474976710655 milliseconds'
>> + interval '250 microseconds')
>> - clock_timestamp()
>> );
> I think that is a non-bug.
> uuidv7(interval) gets the actual current timestamp (just like clock_timestamp
> does) and adds that to the interval argument. That call is a bit later than
> the clock_timestamp in your statement, so the result is maybe bigger than the
> timestamp you specified, so it might exceed the maximum possible timestamp.
I poked at this by instrumenting uuidv7_interval, and verified that
(at least on my machine) we compute values that are two or three or so
microseconds larger than expected, due to the time elapsed between
clock_timestamp() and uuidv7_interval's own clock reading. But this
example would fail even without that effect, because we're rejecting
values larger than UUIDV7_MAX_TIMESTAMP, and the computed result is
bigger than that by 250 microseconds plus that clock offset.
I do think that uuidv7_interval is rather poorly written: it's
bandying around not two but three(!) different clock precisions,
with absolutely no attention paid to the niceties of rounding
off properly when switching precisions. So this bug report is
indeed pointing at something that could be done better. But if
the worst consequence is that you can't reliably generate a
v7 UUID with the maximum clock field value, I doubt anybody is going
to spend time on it. I can't see that that's an interesting use
case, so I think we have far more pressing problems to deal with.
regards, tom lane
