Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL
Date
Msg-id 3f0b79eb1002100119r6ce1b4b7haf2732d5fa8bbfa1@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Make standby server continuously retry restoring the next WAL  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, Feb 10, 2010 at 4:32 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Hmm, so after running restore_command, check the file size and if it's
> too short, treat it the same as if restore_command returned non-zero?

Yes, only in standby mode case. OTOH I think that normal archive recovery
should treat it as a FATAL error.

> And it will be retried on the next iteration. Works for me, though OTOH
> it will then fail to complain about a genuinely WAL file that's
> truncated for some reason. I guess there's no way around that, even if
> you have a script as restore_command that does the file size check, it
> will have the same problem.

Right. But the server in standby mode also needs to complain about that?
We might be able to read completely such a WAL file that looks truncated
from the primary via SR, or from the archive after a few seconds. So it's
odd for me to give up continuing the standby only by finding the WAL file
whose file size is short. I believe that the warm standby (+ pg_standby)
also is based on that thought.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Leonardo F
Date:
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch
Next
From: Kurt Harriman
Date:
Subject: Re: Patch: Remove gcc dependency in definition of inline functions