From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexey Kondratov <a.kondratov@postgrespro.ru>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>
Subject: Re: Misuse of TimestampDifference() in the autoprewarm feature of
 pg_prewarm
In-reply-to: <f36e95736ed8c57d61cfb054fd734194@postgrespro.ru>
References: <3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru>
 <1992985.1604948005@sss.pgh.pa.us>
 <f36e95736ed8c57d61cfb054fd734194@postgrespro.ru>
Comments: In-reply-to Alexey Kondratov <a.kondratov@postgrespro.ru>
	message dated "Mon, 09 Nov 2020 23:03:53 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1996861.1604953516.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Mon, 09 Nov 2020 15:25:16 -0500
Message-ID: <1996862.1604953516@sss.pgh.pa.us>
Precedence: bulk

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