Purpose of wal_init_zero

From: Andy Fan <zhihuifan1213(at)163(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Purpose of wal_init_zero
Date: 2025-01-15 09:12:17
Message-ID: 87a5bs5tla.fsf@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-01-15 09:27:22 Re: per backend I/O statistics
Previous Message Shlok Kyal 2025-01-15 09:11:18 Re: Pgoutput not capturing the generated columns