Re: Fix for pg_upgrade status display

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Fix for pg_upgrade status display
Дата
Msg-id 20121206185736.GM30893@momjian.us
обсуждение исходный текст
Ответ на Re: Fix for pg_upgrade status display  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Dec  6, 2012 at 02:53:44PM -0300, Alvaro Herrera wrote:
> Robert Haas escribió:
> > On Wed, Dec 5, 2012 at 10:04 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > > Pg_upgrade displays file names during copy and database names during
> > > dump/restore.  Andrew Dunstan identified three bugs:
> > >
> > > *  long file names were being truncated to 60 _leading_ characters, which
> > > often do not change for long file names
> > >
> > > *  file names were truncated to 60 characters in log files
> > >
> > > *  carriage returns were being output to log files
> > >
> > > The attached patch fixes these --- it prints 60 _trailing_ characters to
> > > the status display, and full path names without carriage returns to log
> > > files.
> > 
> > This might be a dumb question, but why limit it to 60 characters at
> > all instead of, say, MAXPGPATH?
> 
> I think this should be keyed off the terminal width, actually, no?  The
> whole point of this is to overwrite the same line over and over, right?

That seems like overkill for a status message.  It is just there so
users know pg_upgrade isn't stuck, which was the complaint before the
message was used.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Fix for pg_upgrade status display
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Setting visibility map in VACUUM's second phase