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