Re: [HACKERS] small pg_basebackup display bug

2013-01-17 Thread Magnus Hagander
On Sun, Dec 16, 2012 at 7:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Magnus Hagander mag...@hagander.net writes:
 On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers e...@xs4all.nl wrote:
 That would make such a truncation less frequent, and after all a truncated 
 display is not
 particular useful.

 Agreed - it's useful during testing, but not in a typical production
 use. It might actually be more useful if it's truncated in in the
 other end (keeping the last 30 instead of the first 30 chars)

 +1 for truncating from the left.  I think pg_upgrade already does that
 in its progress messages.

Fixed. I also fixed the output of the size parameter to be a fixed
length, so the whole row doesn't shift left and right depending on how
far long the process is.

--
 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


Re: [HACKERS] small pg_basebackup display bug

2012-12-17 Thread Bruce Momjian
On Sun, Dec 16, 2012 at 01:20:53PM -0500, Tom Lane wrote:
 Magnus Hagander mag...@hagander.net writes:
  On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers e...@xs4all.nl wrote:
  That would make such a truncation less frequent, and after all a truncated 
  display is not
  particular useful.
 
  Agreed - it's useful during testing, but not in a typical production
  use. It might actually be more useful if it's truncated in in the
  other end (keeping the last 30 instead of the first 30 chars)
 
 +1 for truncating from the left.  I think pg_upgrade already does that
 in its progress messages.

Yes, it does in the current git tree.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] small pg_basebackup display bug

2012-12-16 Thread Magnus Hagander
On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers e...@xs4all.nl wrote:
 On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
 On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers e...@xs4all.nl wrote:
 from 9.3devel (this morning):


 The truncated name in parentheses only shows up during the filling of the 
 new PGDATA; when 100%
 is
 reached that part of the displayed name is deleted.  That's another bug in 
 itself, I think:
 shouldn't the end-state of that line also display the parenthesized name?

 Those are both intentional. It may be argued that the intention shoud
 be changed :), but it's not a bug in itself - it's acting like
 intended.


 Fair enough.  How about just changing the possible length to enable display 
 somewhat longer names
 like I used?  It truncates to 30 characters; perhaps something like 100 would 
 be more reasonable?

The general idea with the selection was that it shouldn't truncate on
a normal terminal. 30 might be a bit on the aggressive side, but 100
would be guaranteed to almost always do it (since there is also other
text on the line than just the filename). I'm not sure if we can
figure out the size of the screen in a platform independent way
without going through a lot of extra work though - but maybe we can?

 That would make such a truncation less frequent, and after all a truncated 
 display is not
 particular useful.

Agreed - it's useful during testing, but not in a typical production
use. It might actually be more useful if it's truncated in in the
other end (keeping the last 30 instead of the first 30 chars)

--
 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


Re: [HACKERS] small pg_basebackup display bug

2012-12-16 Thread Tom Lane
Magnus Hagander mag...@hagander.net writes:
 On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers e...@xs4all.nl wrote:
 That would make such a truncation less frequent, and after all a truncated 
 display is not
 particular useful.

 Agreed - it's useful during testing, but not in a typical production
 use. It might actually be more useful if it's truncated in in the
 other end (keeping the last 30 instead of the first 30 chars)

+1 for truncating from the left.  I think pg_upgrade already does that
in its progress messages.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] small pg_basebackup display bug

2012-12-15 Thread Erik Rijkers
from 9.3devel (this morning):

There is a small bug in pg_basebackup: it displays a truncated part of what 
seems to be the new
$PGDATA (the source code has 'filename' there, but I don't see what's supposed 
to be in there).

The truncated name in parentheses only shows up during the filling of the new 
PGDATA; when 100% is
reached that part of the displayed name is deleted.  That's another bug in 
itself, I think:
shouldn't the end-state of that line also display the parenthesized name?

Below is output that shows what I mean: I got that by entering ENTER e few 
times while
pg_basebackup was running

$ pg_basebackup -v -P -D 
/home/aardvark/pg_stuff/pg_installations/pgsql.93_3pulls2/data
19377/55092 kB (35%), 0/1 tablespace (/home/aardvark/pg_stuff/pg_ins)
45859/55092 kB (83%), 0/1 tablespace (/home/aardvark/pg_stuff/pg_ins)
55101/55101 kB (100%), 1/1 tablespace
pg_basebackup: base backup completed


Thanks,

Erik Rijkers







-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] small pg_basebackup display bug

2012-12-15 Thread Magnus Hagander
On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers e...@xs4all.nl wrote:
 from 9.3devel (this morning):

Is this different from 9.2 and earlier?


 There is a small bug in pg_basebackup: it displays a truncated part of what 
 seems to be the new
 $PGDATA (the source code has 'filename' there, but I don't see what's 
 supposed to be in there).

It is the full name of the file. If the path is too long it gets
truncated before it gets to the actual filename, of course, so it
looks to be the directory.


 The truncated name in parentheses only shows up during the filling of the new 
 PGDATA; when 100% is
 reached that part of the displayed name is deleted.  That's another bug in 
 itself, I think:
 shouldn't the end-state of that line also display the parenthesized name?

Those are both intentional. It may be argued that the intention shoud
be changed :), but it's not a bug in itself - it's acting like
intended.

-- 
 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


Re: [HACKERS] small pg_basebackup display bug

2012-12-15 Thread Erik Rijkers
On Sat, December 15, 2012 14:10, Magnus Hagander wrote:
 On Sat, Dec 15, 2012 at 11:39 AM, Erik Rijkers e...@xs4all.nl wrote:
 from 9.3devel (this morning):


 The truncated name in parentheses only shows up during the filling of the 
 new PGDATA; when 100%
 is
 reached that part of the displayed name is deleted.  That's another bug in 
 itself, I think:
 shouldn't the end-state of that line also display the parenthesized name?

 Those are both intentional. It may be argued that the intention shoud
 be changed :), but it's not a bug in itself - it's acting like
 intended.


Fair enough.  How about just changing the possible length to enable display 
somewhat longer names
like I used?  It truncates to 30 characters; perhaps something like 100 would 
be more reasonable? 
That would make such a truncation less frequent, and after all a truncated 
display is not
particular useful.


Thanks,

Erik Rijkers




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers