Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade --logfile option documentation

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --logfile option documentation
Date: 2012-02-22 23:38:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Feb 22, 2012 at 05:49:26PM -0500, Robert Haas wrote:
> On Wed, Feb 22, 2012 at 3:51 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On sön, 2012-02-19 at 13:24 -0500, Robert Haas wrote:
> >> But I also think the
> >> logging needs improvement.  Right now, we studiously redirect both
> >> stdout and stderr to /dev/null; maybe it would be better to redirect
> >> stdout to /dev/null and NOT redirect stderr.  If that generates too
> >> much chatter in non-failure cases, then let's adjust the output of the
> >> commands pg_upgrade is invoking until it doesn't.
> >
> > That should be achievable for calls to psql and vacuumdb, say, but what
> > would you do with the server logs?
> I don't know.  It might be less of an issue, though.  I mean, IME,
> what typically happens is that psql fails to restore the dump, either
> because it can't connect to the new database or because it's confused
> by some stupid case that isn't handled well.  So even if we could just
> improve the error handling to report those types of failures more
> transparently, I think it would be a big improvement.

Well, on Unix, it is easy to redirect the server logs to the same place
as the pg_upgrade logs.  That doesn't help?  How would we improve the
reporting of SQL restore failures?

  Bruce Momjian  <bruce(at)momjian(dot)us>

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

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-02-22 23:40:25
Subject: Re: pg_upgrade --logfile option documentation
Previous:From: Jeff DavisDate: 2012-02-22 23:36:48
Subject: Re: SSI rw-conflicts and 2PC

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group