Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander <magnus(at)hagander(dot)net> wrote in
> On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
> > I believe that the time required to estimate the backup size is not so large
> > in most cases, so in the above idea, most users don't need to specify more
> > option for the estimation. This is good for UI perspective.
> >
> > OTOH, users who are worried about the estimation time can use
> > --no-estimate-backup-size option and skip the time-consuming estimation.
>
> Personally, I think this is the best idea. it brings a "reasonable
> default", since most people are not going to have this problem, and
> yet a good way to get out from the issue for those that potentially
> have it. Especially since we are now already showing the state that
> "walsender is estimating the size", it should be easy enugh for people
> to determine if they need to use this flag or not.
>
> In nitpicking mode, I'd just call the flag --no-estimate-size -- it's
> pretty clear things are about backups when you call pg_basebackup, and
> it keeps the option a bit more reasonable in length.

I agree to the negative option and the shortened name. What if both
--no-estimate-size and -P are specifed? Rejecting as conflicting
options or -P supercedes? I would choose the former because we don't
know which of them has priority.

$ pg_basebackup --no-estimate-size -P
pg_basebackup: -P requires size estimate.
$

regads.

--
Kyotaro Horiguchi
NTT Open Source Software Center