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

Re: pg_upgrade --logfile option documentation

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade --logfile option documentation
Date: 2012-02-22 22:49:26
Message-ID: CA+TgmobYg9C_yBcmz6kEERVqRH_1nqeptT2SnK-2WqXGOed8cQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-22 22:57:05
Subject: Re: WIP: proof of concept patch for fixing quantified regex backrefs
Previous:From: jamesDate: 2012-02-22 22:31:27
Subject: swapcache-style cache?

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