On 2020/03/09 14:21, Magnus Hagander wrote:
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.
+1
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.
+1
So, I will make the patch adding support for --no-estimate-size option
in pg_basebackup.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
