I wrote:
> Actually ... take a close look at the code. The delay is done in
> xact.c between XLogInsert(commitrecord) and XLogFlush(). As near
> as I can tell, both the write() and the fsync() will happen in
> XLogFlush(). This means the delay is just plain broken: placed
> there, it cannot do anything except waste time.
Uh ... scratch that ... nevermind. The point is that we've inserted
our commit record into the WAL output buffer. Now we are sleeping
in the hope that some other backend will do both the write and the
fsync for us, and that when we eventually call XLogFlush() it will find
nothing to do. So the delay is not in the wrong place.
> Another thing I am wondering about is why we're not using fdatasync(),
> where available, instead of fsync(). The whole point of preallocating
> the WAL files is to make fdatasync safe, no?
This still looks like it'd be a win, by reducing the number of seeks
needed to complete a WAL logfile flush. Right now, each XLogFlush
requires writing both the file's data area and its inode.
regards, tom lane