On Fri, 2007-08-31 at 21:56 -0400, Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
> > That all seems reasonable enough. Is it in the docs somewhere? I
> > didn't find anything like this mentioned. If not, could we get it
> > added as a note?
>
> Yeah, it hadn't occurred to anyone to s
On Fri, Aug 31, 2007 at 09:56:50PM -0400, Tom Lane wrote:
> Jeff Frost <[EMAIL PROTECTED]> writes:
> > That all seems reasonable enough. Is it in the docs somewhere? I
> > didn't find anything like this mentioned. If not, could we get it
> > added as a note?
>
> Yeah, it hadn't occurred to anyo
On Fri, 31 Aug 2007, Jeff Frost wrote:
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYX
Jeff Frost <[EMAIL PROTECTED]> writes:
> That all seems reasonable enough. Is it in the docs somewhere? I
> didn't find anything like this mentioned. If not, could we get it
> added as a note?
Yeah, it hadn't occurred to anyone to specify this, because we just
thought of recovery_command as fet
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYXLOG
and only when the "fetch" step fails
Jeff Frost <[EMAIL PROTECTED]> writes:
> Why does it request it twice?
I think the reason is that the rollforward cycle is
fetch next segment into RECOVERYXLOG
process segment
unlink RECOVERYXLOG
and only when the "fetch" step fails does it realize it's done. So then
it
On Fri, 31 Aug 2007, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
It seems like everything is happy, except it seems to ask for the 4F
log file more than once.
IIRC that's standard procedure. Is there a reason your recovery_command
can't support it?
Really? If that's the case, t
Jeff Frost <[EMAIL PROTECTED]> writes:
> It seems like everything is happy, except it seems to ask for the 4F
> log file more than once.
IIRC that's standard procedure. Is there a reason your recovery_command
can't support it?
regards, tom lane
--
Hi guys, I've inherited a PITR continuous recovery master/standby server pair.
The continuous recovery and loading of the xlogs seems to work fine, but when
I opted to test the replica bring up, it falls over with signal 6.
Here's an excerpt from the log with log levels set up to debug5:
DEBUG
