Re: pg_upgrade verbosity when redirecting output to log file - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade verbosity when redirecting output to log file
Date
Msg-id YdxTyKo6zYxfq7HO@momjian.us
Whole thread Raw
In response to Re: pg_upgrade verbosity when redirecting output to log file  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_upgrade verbosity when redirecting output to log file
List pgsql-hackers
On Sun, Jan  9, 2022 at 10:39:58PM -0800, Andres Freund wrote:
> Hi,
> 
> On 2022-01-10 01:14:32 -0500, Tom Lane wrote:
> > Andres Freund <andres@anarazel.de> writes:
> > Fun!  That seems to me to be a strong argument for not letting
> > the behavior vary depending on isatty().
> 
> Yea.
> 
> 
> > I think I'd vote for just nuking that output altogether.
> > It seems of very dubious value.
> 
> It seems worthwhile in some form - on large cluster in copy mode, the "Copying
> user relation files" step can take *quite* a while, and even link/clone mode
> aren't fast. But perhaps what'd be really needed is something counting up
> actual progress in percentage of files and/or space...
> 
> I think just coupling it to verbose mode makes the most sense, for now?

All of this logging is from the stage where I was excited pg_upgrade
worked, and I wanted to give clear output if it failed in some way ---
printing the file names seems like an easy solution.  I agree at this
point that logging should be reduced, and if they want more logging, the
verbose option is the right way to get it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Undocumented behavior of timezone(zone, timestamp) for impossible timestamptz's
Next
From: Andrew Dunstan
Date:
Subject: Re: Windows crash / abort handling