Re: WAL and commit_delay

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> The implication is that the only thing you can lose after fdatasync is
> the highly-inessential file mod time. However, I have been told that
> on some implementations, fdatasync only flushes data blocks, and never
> writes the inode or indirect blocks. That would mean that if you had
> allocated new disk space to the file, fdatasync would not guarantee
> that that allocation was reflected on disk. This is the reason for
> preallocating the WAL log file (and doing a full fsync *at that time*).
> Then you know the inode block pointers and indirect blocks are down
> on disk, and so fdatasync is sufficient even if you have the cheesy
> version of fdatasync.

Actually, there is also a performance reason. Indeed, fdatasync would
not perform any better than fsync if the log file was not
preallocated: the file length would change each time a record is
appended, and therefore the inode would have to be updated.

-- Jerome