MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 12 Nov 2020 13:47:34 +0300
From: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Misuse of TimestampDifference() in the autoprewarm feature of
 pg_prewarm
In-Reply-To: <2464589.1605067173@sss.pgh.pa.us>
References: <3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru>
 <1992985.1604948005@sss.pgh.pa.us>
 <f36e95736ed8c57d61cfb054fd734194@postgrespro.ru>
 <1996862.1604953516@sss.pgh.pa.us>
 <01241062b6bfea2f17e32a65a4f99d61@postgrespro.ru>
 <2464589.1605067173@sss.pgh.pa.us>
User-Agent: Roundcube Webmail/1.4.0
Message-ID: <221de228fbf0c801e335bd3bcc661a31@postgrespro.ru>
Precedence: bulk

On 2020-11-11 06:59, Tom Lane wrote:
> Alexey Kondratov <a.kondratov@postgrespro.ru> writes:
>> After looking on the autoprewarm code more closely I have realised 
>> that
>> this 'double dump' issues was not an issues at all. I have just
>> misplaced a debug elog(), so its second output in the log was only
>> indicating that we calculated delay_in_ms one more time.
> 
> Ah --- that explains why I couldn't see a problem.
> 
> I've pushed 0001+0002 plus some followup work to fix other places
> that could usefully use TimestampDifferenceMilliseconds().  I have
> not done anything with 0003 (the TAP test for pg_prewarm), and will
> leave that to the judgment of somebody who's worked with pg_prewarm
> before.  To me it looks like it's not really testing things very
> carefully at all; on the other hand, we have exactly zero test
> coverage of that module today, so maybe something is better than
> nothing.
> 

Great, thank you for generalisation of the issue and working on it.


Regards
-- 
Alexey Kondratov

Postgres Professional https://www.postgrespro.com
Russian Postgres Company