Re: Progress reporting for pg_verify_checksums

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Progress reporting for pg_verify_checksums
Дата
Msg-id 20190319.090414.137724997.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Progress reporting for pg_verify_checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Progress reporting for pg_verify_checksums
Список pgsql-hackers
Hello.

At Mon, 18 Mar 2019 23:14:01 +0100 (CET), Fabien COELHO <coelho@cri.ensmp.fr> wrote in
<alpine.DEB.2.21.1903182311130.23282@lancre>
>
> > I have rebased it now.
>
> Thanks. Will look at it.
>
> >> If the all of aboves are involved, the line would look as the
> >> follows.
> >>
> >> [=======================             ] ( 63% of 12.53 GB, 179 MB/s,
> >> ETC 26s)
> >>
> >> # Note that this is just an opinion.
> >>
> >> (pg_checksum runs fast at the beginning so ETC behaves somewhat
> >> strange in the meanwhile.)
> >
> > I haven't changed that for now as it seems to be a bit more involved.
> > I'd like to hear other opinions on whether that is worthwhile?
> I think that the bar is overkill, but ETC is easy and nice.

I'm fine with that.

> >>> +     /* we handle SIGUSR1 only, and toggle the value of show_progress
> >>> */
> >>> +     if (signum == SIGUSR1)
> >>> +             show_progress = !show_progress;
> >>
> >> SIGUSR1 *toggles* progress.
> >
> > Not sure what you mean here,
>
> Probably it is meant to simplify the comment?

Sorry. I meant that "it can be turned off and a perhaps-garbage
line is left alone after turning off. Don't we need to erase it?".

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matheus de Oliveira
Дата:
Сообщение: Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons