Alexey Kondratov <a.kondratov@postgrespro.ru> writes:
> On 2020-11-09 21:53, Tom Lane wrote:
>> 0002 seems like a pretty clear bug fix, though I wonder if this is exactly
>> what we want to do going forward. It seems like a very large fraction of
>> the callers of TimestampDifference would like to have the value in msec,
>> which means we're doing a whole lot of expensive and error-prone
>> arithmetic to break down the difference to sec/usec and then put it
>> back together again. Let's get rid of that by inventing, say
>> TimestampDifferenceMilliseconds(...).
> Yeah, I get into this problem after a bug in another extension —
> pg_wait_sampling. I have attached 0002, which implements
> TimestampDifferenceMilliseconds(), so 0003 just uses this new function
> to solve the initial issues. If it looks good to you, then we can switch
> all similar callers to it.
Yeah, let's move forward with that --- in fact, I'm inclined to
back-patch it. (Not till the current release cycle is done, though.
I don't find this important enough to justify a last-moment patch.)
BTW, I wonder if we shouldn't make TimestampDifferenceMilliseconds
round any fractional millisecond up rather than down. Rounding down
seems to create a hazard of uselessly waking just before the delay is
completed. Better to wake just after.
I still think your 0001 is fishy, but don't have time today to stare at
it more closely.
regards, tom lane
