Re: pg_standby testing notes

On Thu, 2007-01-11 at 14:20 -0500, Merlin Moncure wrote:

> I am looking into using pg_standby (v3) in a warm standby system. I'm
> going to double check it, but same machine replication seemed to work
> ok. When I tried to do remote server log shipping however, I had some
> issues.
>
> Initial setup and launch is working ok, my archive command is:
> 'test ! -f /var/lib/pgsql/pitr/%f && cp %p /var/lib/pgsql/pitr/%f'
>
> my restore command is:
> pg_standby -m -t/raid/pitr/kill /raid/pitr %f %p
>
> '/raid/pitr' is an nfs mount mounted from the primary to the standby.
> I suspect the problem lies there, but I thought I'd ask. here is my
> log on the standby following a fresh pitr load:
>
> 2007-01-11 07:40:37 EST : LOG: automatic recovery in progress
> 2007-01-11 07:40:37 EST : LOG: redo starts at 0/630000B0
> 2007-01-11 07:41:37 EST : LOG: restored log file
> "000000010000000000000064" from archive
> 2007-01-11 07:41:38 EST : LOG: restored log file
> "000000010000000000000065" from archive
> 2007-01-11 07:41:38 EST : LOG: restored log file
> "000000010000000000000066" from archive
> 2007-01-11 07:51:44 EST : LOG: could not open file
> "pg_xlog/000000010000000000000067" (log file 0, segment 103): No such
> file or directory
> 2007-01-11 07:51:44 EST : LOG: redo done at 0/66FFFFC8
> 2007-01-11 08:01:49 EST : PANIC: could not open file
> "pg_xlog/000000010000000000000066" (log file 0, segment 102): No such
> file or directory
>
> neither the primary or the standby are in production...the 3 restored
> files were from me manufacturing work on the primary to generate
> files. Is there anything obvious I should be checking?

All log lines are normal, apart from the PANIC...

This looks familiar to me; I see from my notes that I wanted to exclude
-m option, but I left it in. On review, I can't see how -m would work at
all without a (minor) change to the backend - it works... apart from the
very last file request.

Can you try -l and see if that works instead? It should perform the
same, roughly.

Thanks for your feedback.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com