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