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

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi(dot)shinoda(at)hpe(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, masahiko(dot)sawada(at)2ndquadrant(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side
Date: 2020-03-10 09:09:01
Message-ID: 16ef30f3-f4d6-1dea-b807-e0936c7532c6@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(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.
>
> +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

Attachment Content-Type Size
add_no_estimate_size_v1.patch text/plain 7.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-03-10 09:14:36 Re: Berserk Autovacuum (let's save next Mandrill)
Previous Message Kyotaro Horiguchi 2020-03-10 08:57:55 Re: Improve handling of parameter differences in physical replication