On Sep 13, 2007, at 3:02 PM, Jeff Davis wrote:
On Thu, 2007-09-13 at 14:05 -0500, Erik Jones wrote:
If you include the -d option pg_standby will emit logging info on
stderr so you can tack on something like 2>> logpath/standby.log.
What it is lacking, however, is timestamps in the output when it
successfully recovers a WAL file. Was there something more ou were
looking for?
I don't think the timestamps will be a problem, I can always pipe it
through something else.
I think this will work, but it would be nice to have something
that's a
little more well-defined and standardized to determine whether some
kind
of error happens during replay.
Right. The problem there is that there really isn't anything
standardized about pg_standby, yet. Or, if it is, it hasn't been
documented, yet. Perhaps you could ask Simon about the possible
outputs on error conditions so that you'll have a definite list to
work with?
Ultimately, what I'm trying to do is make it so that pgsnmpd can
monitor
this, and trap if a problem occurs. In order for pgsnmpd to do this
in a
way that works for a large number of people, it can't make too many
assumptions about logging options, etc.
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
