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? The additional synchronizations you suggest are neither necessary, nor IMHO desirable. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
