On Tue, Aug 16, 2011 at 10:33, Peter Eisentraut <peter_e@gmx.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@gmx.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/