Re: Failing start-up archive recovery at Standby mode in PG9.2.4

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

In response to

Responses

Browse pgsql-hackers by date

  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