VACUUM VERBOSE output to STDERR
Hello,
I'm trying to solve a little issue: I wish to redirect my cron
jobs'output to log files. STDOUT redirection is done inside the crontab,
but VACUUM still yields its messages[1]e.g.: <snip> NOTICE: --Relation pg_type-- NOTICE: Pages 3: Changed 0, Empty 0; Tup 145: Vac 0, Keep 0, UnUsed 2. Total CPU 0.00s/0.00u sec elapsed 0.07 sec. NOTICE: Analyzing pg_type NOTICE: --Relation pg_attribute-- NOTICE: Pages 12: Changed 0, Empty 0; Tup 827: Vac 0, Keep 0, UnUsed 32. Total CPU 0.00s/0.00u sec elapsed 0.00 sec. NOTICE: Analyzing pg_attribute </snip> through, onto STDERR, I guess.
I wouldn't like to '2>&1' also: I wish I could keep STDERR (what if an
error condition must be reported ?).
Is there a way to do so ?
Thanks in advance,
BR,
Francis
[1]: e.g.: <snip> NOTICE: --Relation pg_type-- NOTICE: Pages 3: Changed 0, Empty 0; Tup 145: Vac 0, Keep 0, UnUsed 2. Total CPU 0.00s/0.00u sec elapsed 0.07 sec. NOTICE: Analyzing pg_type NOTICE: --Relation pg_attribute-- NOTICE: Pages 12: Changed 0, Empty 0; Tup 827: Vac 0, Keep 0, UnUsed 32. Total CPU 0.00s/0.00u sec elapsed 0.00 sec. NOTICE: Analyzing pg_attribute </snip>
<snip>
NOTICE: --Relation pg_type--
NOTICE: Pages 3: Changed 0, Empty 0; Tup 145: Vac 0, Keep 0, UnUsed 2.
Total CPU 0.00s/0.00u sec elapsed 0.07 sec.
NOTICE: Analyzing pg_type
NOTICE: --Relation pg_attribute--
NOTICE: Pages 12: Changed 0, Empty 0; Tup 827: Vac 0, Keep 0, UnUsed
32. Total CPU 0.00s/0.00u sec elapsed 0.00 sec.
NOTICE: Analyzing pg_attribute
</snip>
On Fri, 11 Aug 2006 15:49:56 +0200
Francis GUDIN <fgudin@cri74.org> wrote:
Hello,
I'm trying to solve a little issue: I wish to redirect my cron
jobs'output to log files. STDOUT redirection is done inside the
crontab, but VACUUM still yields its messages[1] through, onto
STDERR, I guess. I wouldn't like to '2>&1' also: I wish I could keep
STDERR (what if an error condition must be reported ?).
Is there a way to do so ?Thanks in advance,
BR,
Francis
Francis,
Take a look at the "tee" command that takes stdin and writes it to
stdout AND a file. If I understand you correctly you DO want to keep
stdout and stderr as two separate streams, write (at least) std err to
a log file, but have the error messages e-mailed to you as part of your
cron job. The command line for that might look something like:
ls tmp/nofile tmp/goodfile 2>&1 1>tmp/nofile.txt | tee tmp/nofile.err
Here I've run the command ls on two files, one that exixts, and one
that doesn't. In the first half (before the pipe or bar) I've
redirected stdout to a file called "nofile.txt" and THEN redirected
stderr to stdout. Redirection is read right to left just to be
exciting.
I pipe the result (stderr on stdout's descriptor) to the tee command
which redirects stdout (stderr from the ls command) to another file
AND prints it to stdout or the screen.
Personally I don't think this is a neat solution but has the virtue of
working. My own understanding of redirection is rudimentary at best.
It's a topic well worth researching on it's own merit.
Good luck.
John Purser
On Fri, 11 Aug 2006 08:05:44 -0700
John Purser <jmpurser@gmail.com> wrote:
Take a look at the "tee" command that takes stdin and writes it to
stdout AND a file. If I understand you correctly you DO want to keep
stdout and stderr as two separate streams, write (at least) std err to
a log file, but have the error messages e-mailed to you as part of
your cron job. <snip>
Thanks for your suggestion, but my concern is more about vacuum's
behaviour, in fact:
those messages are purely /informative/ and get sent to STDERR.
This seems wrong to me: 'mundane' activity should be output to STDOUT and
'exceptional conditions' deserve the special fd, don't they ?
Francis
On Fri, Aug 11, 2006 at 06:10:48PM +0200, Francis GUDIN wrote:
On Fri, 11 Aug 2006 08:05:44 -0700
John Purser <jmpurser@gmail.com> wrote:Take a look at the "tee" command that takes stdin and writes it to
stdout AND a file. If I understand you correctly you DO want to keep
stdout and stderr as two separate streams, write (at least) std err to
a log file, but have the error messages e-mailed to you as part of
your cron job. <snip>Thanks for your suggestion, but my concern is more about vacuum's
behaviour, in fact:
those messages are purely /informative/ and get sent to STDERR.
This seems wrong to me: 'mundane' activity should be output to STDOUT and
'exceptional conditions' deserve the special fd, don't they ?
Well, I don't think psql or libpq really distinguishes them that much.
Normally you just set client_min_messages to suppress the messages you
don't want.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Date: Thu, 17 Aug 2006 12:48:56 +0200
From: Francis GUDIN <fgudin@cri74.org>
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: John Purser <jmpurser@gmail.com>, pgsql-general@postgresql.org
Subject: Re: [GENERAL] VACUUM VERBOSE output to STDERR
Message-ID: <20060817124856.6bce4c9c@pc07.cri.cur-archamps.fr>
In-Reply-To: <20060811165124.GC950@svana.org>
References: <20060811154956.5b04ddb3@pc07.cri.cur-archamps.fr>
<20060811080544.c49c9499.jmpurser@gmail.com>
<20060811181048.435f2076@pc07.cri.cur-archamps.fr>
<20060811165124.GC950@svana.org>
Organization: Centre de Ressources Informatiques de Haute-Savoie
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi,
On Fri, 11 Aug 2006 18:51:24 +0200
Martijn van Oosterhout <kleptog@svana.org> wrote:
Well, I don't think psql or libpq really distinguishes them
that much.
Normally you just set client_min_messages to suppress the
messages you
don't want.
I found a few (different) references to that parameter on the
web, but
either ways (through DBD::Pg or with psql) fail:
SET client_min_messages = WARNING;
yields "ERROR: 'client_min_messages' is not a valid option name"
I've got the feeling that it's a server-side global
configuration knob,
not accessible on a client by client basis, am I right ?
Francis
Import Notes
Resolved by subject fallback
On Thu, Aug 17, 2006 at 12:51:24PM +0200, fgudin wrote:
I found a few (different) references to that parameter on the
web, but
either ways (through DBD::Pg or with psql) fail:
SET client_min_messages = WARNING;
yields "ERROR: 'client_min_messages' is not a valid option name"I've got the feeling that it's a server-side global
configuration knob,
not accessible on a client by client basis, am I right ?
You must be running something terribly old then, 7.4 had it at least
and that's several years old already...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.