On Fri, Jul 16, 2010 at 7:43 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 16/07/10 10:40, Fujii Masao wrote:
>>
>> So we should always prevent the standby from applying any WAL in pg_xlog
>> unless walreceiver is in progress. That is, if there is no WAL available
>> in the archive, the standby ignores pg_xlog and starts walreceiver
>> process to request for WAL streaming.
>
> That completely defeats the purpose of storing streamed WAL in pg_xlog in
> the first place. The reason it's written and fsync'd to pg_xlog is that if
> the standby subsequently crashes, you can use the WAL from pg_xlog to
> reapply the WAL up to minRecoveryPoint. Otherwise you can't start up the
> standby anymore.
But, the standby can start up by reading the missing WAL files from the
master. No?
On the second thought, minRecoveryPoint can be guaranteed to be older
than the fsync location on the master if we'll prevent the standby from
applying the WAL files more than the fsync location. So we can safely
apply the WAL files in pg_xlog up to minRecoveryPoint.
Consequently, we should always prevent the standby from applying any
newer WAL in pg_xlog than minRecoveryPoint unless walreceiver is in
progress. Thought?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center