Re: WAL and commit_delay

> > 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.

Don't we have to fsync the inode too?  Actually, I was hoping sequential
fsync's could sit on the WAL disk track, but I can imagine it has to
seek around to hit both areas.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026