Thread: some missing internationalization in pg_basebackup
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.
I'm just posting it here as an open item in case someone has some ideas
in the meantime.
static void
progress_report(int tablespacenum, char *fn)
{ int percent = (int) ((totaldone / 1024) * 100 / totalsize);
if (percent > 100) percent = 100;
if (verbose) { if (!fn)
/* * No filename given, so clear the status line (used for last * call) */
fprintf(stderr, INT64_FORMAT "/" INT64_FORMAT " kB (100%%) %d/%d tablespaces %35s\r",
totaldone / 1024, totalsize, tablespacenum, tablespacecount, ""); else
fprintf(stderr, INT64_FORMAT "/" INT64_FORMAT " kB (%d%%) %d/%d tablespaces (%-30.30s)\r",
totaldone / 1024, totalsize, percent, tablespacenum, tablespacecount, fn); }
else fprintf(stderr, INT64_FORMAT "/" INT64_FORMAT " kB (%d%%) %d/%d tablespaces\r", totaldone /
1024,totalsize, percent, tablespacenum, tablespacecount);
}
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. > > I'm just posting it here as an open item in case someone has some ideas > in the meantime. Hm. i didn't consider translation at all when writing that. Looking at it from that perspective, I realize it's pretty darn hard to make it translatable. 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.. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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.
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/
Magnus Hagander <magnus@hagander.net> writes: > 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? Yes. If you're interested into the progress being made and the goal is moving, it's better to know about that. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Tue, Aug 16, 2011 at 11:35, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> 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? > > Yes. If you're interested into the progress being made and the goal is > moving, it's better to know about that. Done and applied. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/