On 16/07/10 20:26, Dimitri Fontaine wrote:
> Le 16 juil. 2010 à 12:43, Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> a écrit :
>
>> 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
andfsync'd to pg_xlog is that if the standby subsequently crashes, you can use the WAL from pg_xlog to reapply the WAL
upto minRecoveryPoint. Otherwise you can't start up the standby anymore.
>
> I guess we know for sure that this point has been fsync()ed on the Master, or that we could arrange it so that we
knowthat?
At the moment we only stream WAL that's already been fsync()ed on the
master, so we don't have this problem, but Fujii is proposing to change
that.
I think that's a premature optimization, and we should not try to change
that. There is no evidence from field (granted, streaming replication is
a new feature) or from performance tests that it is a problem in
practice, or that sending WAL earlier would help. Let's concentrate on
the bare minimum required to make synchronous replication work.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com