On Tue, Aug 16, 2011 at 10:33, Peter Eisentraut <pete...@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 <pete...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
