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
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 |