Re: Purpose of wal_init_zero

Hi.

Em qua., 15 de jan. de 2025 às 06:12, Andy Fan <zhihuifan1213(at)163(dot)com>
escreveu:

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

best regards,
Ranier Vilela