I'm having the same problem. In my case, and as recommended in the official documentation, my archive command checks that the file exists first, before archiving it:
archive_command = 'test ! -f /ORA/dbs02/PGTEST/archive/%f && cp %p /ORA/dbs02/PGTEST/archive/%f'
After a successful recovery, the last WAL file replayed from the base archive is still in the pg_xlog directory, so when it tries to archive it, it fails:
LOG: database system was interrupted; last known up at 2013-07-02 14:53:37 CEST
LOG: creating missing WAL directory "pg_xlog/archive_status"
LOG: starting point-in-time recovery to 2013-07-02 15:20:12+02
LOG: restored log file "000000010000000000000002" from archive
LOG: redo starts at 0/2000020
LOG: consistent recovery state reached at 0/20023D0
LOG: restored log file "000000010000000000000003" from archive
LOG: recovery stopping before commit of transaction 4063, time 2013-07-02 15:20:12.211559+02
LOG: redo done at 0/306D8B8
LOG: last completed transaction was at log time 2013-07-02 15:20:11.189978+02
cp: cannot stat `/ORA/dbs02/PGTEST/archive/00000002.history': No such file or directory
LOG: selected new timeline ID: 2
cp: cannot stat `/ORA/dbs02/PGTEST/archive/00000001.history': No such file or directory
LOG: archive recovery complete
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: test ! -f /ORA/dbs02/PGTEST/archive/000000010000000000000003 && cp pg_xlog/000000010000000000000003 /ORA/dbs02/PGTEST/archive/000000010000000000000003
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: test ! -f /ORA/dbs02/PGTEST/archive/000000010000000000000003 && cp pg_xlog/000000010000000000000003 /ORA/dbs02/PGTEST/archive/000000010000000000000003
LOG: archive command failed with exit code 1
DETAIL: The failed archive command was: test ! -f /ORA/dbs02/PGTEST/archive/000000010000000000000003 && cp pg_xlog/000000010000000000000003 /ORA/dbs02/PGTEST/archive/000000010000000000000003
WARNING: transaction log file "000000010000000000000003" could not be archived: too many failures
Is this a expected behaviour? Or should the px_log directory be cleaned-up again on recovery_end_command ? Cheers
View this message in context:
Re: PostgreSQL archiving last replayed WAL after recovery Sent from the
PostgreSQL - general mailing list archive at Nabble.com.
