Hi,
cc: Andrey
> Over in the thread discussing the addition of UUIDv7 support [0], there
> is some uncertainty about what timestamp precision one can expect from
> gettimeofday().
>
> UUIDv7 uses milliseconds since Unix epoch, but can optionally use up to
> 12 additional bits of timestamp precision (see [1]), but it can also
> just use a counter instead of the extra precision. The current patch
> uses the counter method "because of portability concerns" (source code
> comment).
>
> I feel that we don't actually have any information about this
> portability concern. Does anyone know what precision we can expect from
> gettimeofday()? Can we expect the full microsecond precision usually?
Specifically in the UUIDv7 application the goal is to generate not
necessarily time-precise UUIDs but rather do our best to get *unique*
UUIDs. As I understand, this is the actual reason why the patch needs
counters.
As Linux man page puts it:
"""
The time returned by gettimeofday() is affected by discontinuous jumps
in the system time (e.g., if the system administrator manually
changes the system time).
"""
On top of that MacOS man page says:
"""
The resolution of the system clock is hardware dependent, and the time
may be updated continuously or in ``ticks.''
"""
On Windows our gettimeofday() implementation is a wrapper for
GetSystemTimePreciseAsFileTime(). The corresponding MSDN page [1] is
somewhat laconic.
Considering the number of environments PostgreSQL can run in (OS +
hardware + virtualization technologies) and the fact that
hardware/software changes I doubt that it's realistic to expect any
particular guarantees from gettimeofday() in the general case.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime
--
Best regards,
Aleksander Alekseev
