Re: pg_standby observation

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

In response to

Responses

Browse pgsql-general by date

  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