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.comPostgreSQL Training, Services and Support
