Re: Progress reporting for pg_verify_checksums

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: Progress reporting for pg_verify_checksums
Дата
Msg-id alpine.DEB.2.21.1903271509220.14554@lancre
обсуждение исходный текст
Ответ на Re: Progress reporting for pg_verify_checksums  (Michael Banck <michael.banck@credativ.de>)
Ответы Re: Progress reporting for pg_verify_checksums
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PostgreSQL pollutes the file system
Следующее
От: Andreas Karlsson
Дата:
Сообщение: Re: PostgreSQL pollutes the file system