On Sun, 2007-09-16 at 11:18 -0700, Jeff Davis wrote:
On Sun, 2007-09-16 at 09:25 +0100, Simon Riggs wrote:
Well, the definition of it working correctly is that a restored log
file... message occurs. Even with archive_timeout set there could be
various delays before that happens. We have two
On Thu, 2007-09-13 at 15:13 -0500, Erik Jones wrote:
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
On Thu, 2007-09-13 at 11:38 -0700, 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,
On Sun, 2007-09-16 at 09:25 +0100, Simon Riggs wrote:
Well, the definition of it working correctly is that a restored log
file... message occurs. Even with archive_timeout set there could be
various delays before that happens. We have two servers and a network
involved, so the time might spike
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
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
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
