Re: some missing internationalization in pg_basebackup

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some missing internationalization in pg_basebackup
Date: 2011-08-16 08:38:08
Message-ID: CABUevEy10PhPVZAFJSdDcZnDop0JM6aqRBoFhnsWXgDTZ_Ok=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 16, 2011 at 10:33, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On ons, 2011-08-10 at 11:39 +0200, Magnus Hagander wrote:
>> On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> > I noticed that the progress reporting code in pg_basebackup does not
>> > allow for translation.  This would normally be easy to fix, but this
>> > code has a number of tricky issues, including the INT64_FORMAT, possibly
>> > some plural concerns, and some space alignment issues that hidden in
>> > some of those hardcoded numbers.
>
>> Maybe it can/should be rewritten not to try to do all those things in
>> one step, thus making it easier somehow? I'm afraid I don't know
>> enough about the translation system to know exactly what would go all
>> the way there, though..
>
> I've fixed this now.
>
> During testing, I noticed that the final kB number always overshoots the
> projected total by 1 kB, e.g.,
>
> 52763/52762 kB (100%), 1/1 tablespace
>
> This happens even in trivial test (base backup of regression test
> database, for example), so is it possible that there is some counting
> bug in the code?  It could appear as "postgres can't count" to the user.

Hmm. I bet that's the backup label file. It doesn't exist in the data
directory anymore when we do these backups, but it is synthesized into
the straem. Thus it's not counted.

I wonder if we should bother counting it, or just adjust pg_basebackup
so that it always ends up at exactly 100% by the numbers as well in
cases like this.

Note that the progress indicator will *always* count wrong when you
choose to include WAL, since we just don't know how much WAL there
should be. I guess in this case we could just advance the "end
counter" as well as we go, making sure it doesn't shoot above 100%.

Does that seem reasonable?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-08-16 08:41:41 Re: walprotocol.h vs frontends
Previous Message Magnus Hagander 2011-08-16 08:35:35 Re: walprotocol.h vs frontends