From: | Kyotaro HORIGUCHI <kyota(dot)horiguchi(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Failing start-up archive recovery at Standby mode in PG9.2.4 |
Date: | 2013-04-24 10:16:12 |
Message-ID: | CAM103DvJHSBYdFwhy6f4jmHvg9AGhxCunzeYGikcfekPAGqp3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
> > cp: cannot stat `../arc/000000030000000000000013': そのようなファイルやディレクトリはありません
> > [Standby] 2013-04-22 01:27:25 EDTLOG: 00000: restored log file "000000020000000000000013" from archive
> I can't read the error message here, but this looks suspicious.
The error message is "No such file or directory" in Japanese :-).
Perhaps restore_command is 'cp ../arc/%f %p'.
> The recovery command seems to be returning success although it prints such
an error message?
It seems that, on 9.2.4, RestoreArchivedFile returns expected xlog
filename even if the restore command ends up in failure. And the
caller XLogFileOpen successfully ets and returns fd for the filename
if the file exists since before the restoration attempt. It does not
matter when the existing file and the file expected to be restored are
identical in content.
If the segment includes the timeline increment point, something might
happen, I suppose..
regards,
--
Kyotaro Horiguchi
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2013-04-24 10:25:10 | Re: Failing start-up archive recovery at Standby mode in PG9.2.4 |
Previous Message | Simon Riggs | 2013-04-24 09:24:04 | Re: Fast promotion, loose ends |