On Sun, Mar 8, 2020 at 10:13 PM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander <mag...@hagander.net> > wrote in > > On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao <masao.fu...@oss.nttdata.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/
