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. With this > patch I get less surprising behavior: > > [...] > > The code is a little more tied to TimestampTz being measured in > microseconds than it was before, but it wouldn't really be much > harder to fix if we ever change that.
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). Otherwise, the code seems to match float8_timestamptz() somewhat closely, although I doubt it's worth trying to unify the implementations. -- nathan
