Re: Progress reporting for pg_verify_checksums

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, alvherre(at)2ndquadrant(dot)com, mailings(at)oopsware(dot)de, thomas(dot)munro(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Progress reporting for pg_verify_checksums
Date: 2019-03-28 08:41:57
Message-ID: alpine.DEB.2.21.1903280856130.20516@lancre
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers


Hallo Michael,

>> Or anything which converts to double early.

> Are you sure, seeing elapsed is a double already?

Argh, I missed that. You are right that a double elapsed is enough for the
second part. However, with

+ current_speed = (current_size / MEGABYTES) / (elapsed / 1000.0);

the first division is an integer one because both operands are ints, so
megabytes conversion is rounded down. I'd suggest:

+ current_speed = ((double) current_size / MEGABYTES) / (elapsed / 1000);

> If I print out two additional fractional digits for current_speed, I get
> two non-zero numbers, are those garbage?

Nope, they come from the other divisions, but the fist division will have
wipped out 0.5 MiB on average.

>> Ok, it is more complicated that it looks for large sizes if second is not
>> the right display unit.
>
> Right, new version attached.

Applies, compiles, global & local "make check" (although not tested) ok,
doc build ok, manual tests ok.

Otherwise a very minor comment: I'd invert !force and the computations in
the return condition to avoid the computations when not needed.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2019-03-28 08:48:12 Re: Progress reporting for pg_verify_checksums
Previous Message Christoph Berg 2019-03-28 08:38:16 Re: Enable data checksums by default