Обсуждение: 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] 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>

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/
> 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

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/
> From each according to his ability. To each according to his ability to litigate.