From: | Erik Jones <erik(at)myemma(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(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 19:05:30 |
Message-ID: | 9EB162AA-8DB3-40AD-AEE1-E34A88A317FD@myemma.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sep 13, 2007, at 1:38 PM, Jeff Davis wrote:
> I think it would be useful if pg_standby (in version 8.3 contrib)
> could
> be observed in some way.
>
> Right now I use my own standby script, because every time it runs, it
> touches a file in a known location. That allows me to monitor that
> file,
> and if it is too stale, I know something must have gone wrong (I
> have an
> archive_timeout set), and I can send an SNMP trap.
>
> Would it be useful to add something similar to pg_standby? Is there a
> better way to detect a problem with a standby system, or a more
> appropriate place?
>
> The postgres logs do report this also, but it requires more care to
> properly intercept the "restored log file ... from archive" messages.
>
> Regards,
> Jeff Davis
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?
Erik Jones
Software Developer | Emma®
erik(at)myemma(dot)com
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2007-09-13 20:02:02 | Re: pg_standby observation |
Previous Message | Oleg Bartunov | 2007-09-13 19:02:40 | Re: processing urls with tsearch2 |