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

On Sun, Mar 8, 2020 at 10:13 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> 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.

I would definitely prefer rejecting an invalid combination of options.

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/