Hi,
On Thu, Dec 18, 2008 at 6:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Thu, 2008-12-18 at 12:08 +0900, Fujii Masao wrote:
>
>> >> Agreed, I also think that hard code is better. But I'm nervous that "off"
>> >> keeps us waiting for replication in cases other than DDL, e.g. flush
>> >> buffer, truncate clog, checkpoint.. etc. synchronous_replication = off
>> >> is quite similar to synchronous_commit = off. If we would hard code #4,
>> >> the performance might degrade although it's asynchronous replication.
>> >> So, I'd like to hard code #3. What is your opinion?
>> >
>> > We don't do that when we flush buffer, truncate clog or checkpoint, not
>> > sure why you mention those.
>> >
>> > We ForceSyncCommit when we
>> > * VACUUM FULL
>> > * CREATE/DROP DATABASE or USER
>> > * Create/Drop Tablespace
>> >
>> > I don't see a problem in forcing an fsync for those. I will sleep safer
>> > knowing those guys are on disk even in async mode.
>>
>> If my understanding is correct, XLOG flush is forced up to buffer's LSN
>> when flushing buffer even if asynchronous commit case. Am I missing
>> something?
>
> 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.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
