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.
Can you report the benchmark difference with false (disabled)?
Maybe It's worth considering leaving false as the default.
