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

From Kyotaro HORIGUCHI
Subject Re: Progress reporting for pg_verify_checksums
Date
Msg-id 20190319.090414.137724997.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Progress reporting for pg_verify_checksums  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Progress reporting for pg_verify_checksums
List 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 by date:

Previous
From: Matheus de Oliveira
Date:
Subject: Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT
Next
From: Peter Geoghegan
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons