On 2020/03/10 11:36, Fujii Masao wrote:
>
>
> On 2020/03/09 14:21, Magnus Hagander wrote:
>> On Sun, Mar 8, 2020 at 10:13 PM Kyotaro Horiguchi
>> <horikyota.ntt@gmail.com> wrote:
>>>
>>> At Fri, 6 Mar 2020 09:54:09 -0800, Magnus Hagander <magnus@hagander.net> wrote in
>>>> On Fri, Mar 6, 2020 at 1:51 AM Fujii Masao <masao.fujii@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.
Patch attached.
Regards,
--
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters
