Hi,
On Tue, Dec 23, 2008 at 5:22 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sun, 2008-12-21 at 14:46 +0900, Fujii Masao wrote:
>
>> > XLogFlush() flushes because of an interlock between a dirty buffer write
>> > and an outstanding WAL write. Dirty buffer writes are not replicated, so
>> > there is no need to have a similar interlock on WAL streaming.
>> >
>> > So making those call points synchronous is possible, but neither
>> > necessary or IMHO desirable.
>>
>> Yes in upcoming 8.4, but probably no in the future.
>>
>> What if the primary fails after writing the dirty data buffer before sending
>> the corresponding logs? This would make data on the primary and logs
>> on the standby inconsistent. In 8.4, such inconsistency might not matter
>> because we don't use the data on the failed primary for recovery (when
>> restarting the failed server, we always need a fresh backup). But, since
>> this restriction is not good for some people, in the future, the failed server
>> should restart without a fresh backup, and the inconsistency would be
>> problem. So, I think that the inconsistency should be removed even if
>> asynchronous replication case, and we should enforce "WAL rule" over
>> some servers.
>
> I don't get this argument. Why would we care what happens on the failed server?
It's because, in the future, I'd like to use the data on the failed server when
making it catch up with new primary. This desire might be violated by the
inconsistency which I described.
>
> The additional synchronizations you suggest are neither necessary, nor
> IMHO desirable.
Not additional. It's quite analogous to synchronous_commit.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
