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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026