Nathan Bossart <nathandbossart@gmail.com> writes:
> On Thu, Sep 25, 2025 at 02:42:32PM -0400, Tom Lane wrote:
>> Anyway, I propose trying to get rid of this misbehavior by avoiding
>> floating point in the delay computation, as attached.
> LGTM. I considered suggesting initializing the delay before the loop and
> then updating it at the end of the loop, but that moves the
> CHECK_FOR_INTERRUPTS between the delay calculation and the WaitLatch(),
> which seems like it might extend the sleeps a bit (although that might be
> negligible in practice).
Yeah, I did not consider changing the fundamental logic of the loop.
It's true that this implementation will use a minimum of three
GetCurrentTimestamp() calls where in principle you should need only
two when WaitLatch() doesn't exit early. I'm having a hard time
getting excited about that though. We know that on just about all
current platforms, reading the clock is a handful-of-nanoseconds
operation. (cf. nearby discussion of GNU/Hurd where we found that
that OS is far behind the curve; but I imagine they'll have fixed
that by the time anyone would consider Hurd ready for production.)
So it seems pretty negligible in a function that currently has 1ms
delay resolution and is unlikely to have better than 1us resolution
in the future.
> Otherwise, the code seems to match
> float8_timestamptz() somewhat closely, although I doubt it's worth trying
> to unify the implementations.
Comparing that, I guess I should write USECS_PER_SEC not 1e6.
Not that it'd make a difference now, but in some hypothetical
future where somebody is grepping for dependencies on 1us
TimestampTz resolution, it'd help them find this one.
Thanks for looking at it!
regards, tom lane
