Re: Synchronous replication - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Synchronous replication
Date
Msg-id 4C40A35E.1040502@enterprisedb.com
Whole thread Raw
In response to Re: Synchronous replication  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: putting plproxy in pg_pltemplate
Next
From: Heikki Linnakangas
Date:
Subject: Re: Synchronous replication