Hi,
On Fri, Dec 19, 2008 at 5:50 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Fri, 2008-12-19 at 09:43 +0900, Fujii Masao wrote:
>
>> > Yes, please check the call points for ForceSyncCommit.
>> >
>> > Do I think every xlog flush should be synchronous, no, I don't.
>> That's why we have a user settable parameter for it.
>>
>> Umm.. I focus attention on XLogFlush() called except
>> RecordTransactionCommit().
>> For example, FlushBuffer(), WriteTruncateXlogRec().. etc. These
>> XLogFlush() might
>> flush XLOG synchronously even if asynchronous commit case.
>
> 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
