| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: Misuse of TimestampDifference() in the autoprewarm feature of pg_prewarm |
| Date: | 2020-11-11 03:59:33 |
| Message-ID: | 2464589.1605067173@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2020-11-11 04:11:05 | Re: PATCH: Report libpq version and configuration |
| Previous Message | osumi.takamichi@fujitsu.com | 2020-11-11 03:07:01 | RE: Disable WAL logging to speed up data loading |