Re: Progress reporting for pg_verify_checksums - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Progress reporting for pg_verify_checksums
Date
Msg-id alpine.DEB.2.21.1903271509220.14554@lancre
Whole thread Raw
In response to Re: Progress reporting for pg_verify_checksums  (Michael Banck <michael.banck@credativ.de>)
Responses Re: Progress reporting for pg_verify_checksums
List pgsql-hackers
Hallo Michael,

About patch v12:

Patch applies cleanly, compiles. make check ok, but feature is not tested. 
Doc build ok.

Although I'm in favor of it, I'm not sure that the signal think will make 
it for 12. Maybe it is worth compromising, doing a simple version for now, 
and resubmitting the signal feature later?

ISTM that someone suggested 4 Hz was the good eye speed, but you wait for 
400 ms, which is 2.5 Hz. What about it?

I seems that current_size and total_size are not in the same unit:

  +   if (current_size > total_size)
  +      total_size = current_size / MEGABYTES;

But they should both really be bytes, always.

I think that the computations should be inverted:
  - first adjust total_size to current_size if needed
  - then compute percent
  - remove the percent adjustement as it is <= 100
    since current_size <= total_size

I still think that the speed should compute a double to avoid integer 
rounding errors within the computation. ISTM that rounding should only be 
done for display in the end.

I'm okay with calling the report on each file even if this means every few 
GB...

Someone suggested ETA, and it seems rather simple to do. What about 
adding it?

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PostgreSQL pollutes the file system
Next
From: Andreas Karlsson
Date:
Subject: Re: PostgreSQL pollutes the file system