From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Erik Jones <erik(at)myemma(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Tolley <eggyknap(at)gmail(dot)com> |
Subject: | Re: pg_standby observation |
Date: | 2007-09-13 20:02:02 |
Message-ID: | 1189713722.31777.29.camel@dogma.ljc.laika.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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.
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.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Jones | 2007-09-13 20:13:13 | Re: pg_standby observation |
Previous Message | Erik Jones | 2007-09-13 19:05:30 | Re: pg_standby observation |