Hi, On Thu, Dec 18, 2008 at 6:35 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
