Hi,
It is unclear to me why do we need wal_init_zero. Per comments:
/*
* Zero-fill the file. With this setting, we do this the hard
way to
* ensure that all the file space has really been allocated. On
* platforms that allow "holes" in files, just seeking to the
end
* doesn't allocate intermediate space. This way, we know that
we
* have all the space and (after the fsync below) that all the
* indirect blocks are down on disk. Therefore, fdatasync(2) or
* O_DSYNC will be sufficient to sync future writes to the log
file.
*/
I can understand that "the file space has really been allocated", but
why do we care about this?
One reason I can think of is it has something with "out-of-disk-space"
sistuation, even though what's the benefit of it since we can't do
anything in such case anyway no matter the wal space is pre-alocated or
not?
Another reason I can guess is it provides some performance gain in the
future XLogWrite to that file. However in the normal case, the
wal_init_zero is still under "LWLockAcquire(WALWriteLock,
LW_EXCLUSIVE);" so it cost a lot at first. (more traffic to file system
due to pg_pwrite_zeros and later fsync). I saw "Therefore, fdatasync(2)
or O_DSYNC will be sufficient to sync future writes to the log file. ",
but it is still unclear to me.
I noticed this during a benchmark, where WALWriteLock is waited and the
holder is running WAIT_EVENT_WAL_INIT_WRITE.
--
Best Regards
Andy Fan
