Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Magnus Hagander <magnus@hagander.net>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
"Shinoda, Noriyoshi (PN Japan A&PS Delivery)" <noriyoshi.shinoda@hpe.com>,
Amit Langote <amitlangote09@gmail.com>, masahiko.sawada@2ndquadrant.com,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-03-10T09:09:01Z
Lists: pgsql-hackers
Attachments
- add_no_estimate_size_v1.patch (text/plain) patch v1
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
Commits
-
Report NULL as total backup size if it's not estimated.
- 67e0adfb3f98 13.0 landed
-
Make pg_basebackup ask the server to estimate the total backup size, by default.
- fab13dc50ba5 13.0 landed
-
Report progress of streaming base backup.
- e65497df8f85 13.0 landed