Hi, >> I can understand that "the file space has really been allocated", but >> why do we care about this? >> >> [...] > > Can you report the benchmark difference with false (disabled)? > Maybe It's worth considering leaving false as the default.
Good catch. This comment is not 100% clear to me either. I think that the actual idea of zero-filling *might* be to give the filesystem a hint to allocate sequential blocks for the file, which may be beneficial if WAL is stored on HDD (which arguably few people do in 2025). This GUC was added not a long time ago in 2019, see commit 475861b2615d and discussion [1]. I didn't read the entire thread (yet?) but it looks like the actual purpose of the GUC is to *disable* zero-filling on the filesystems with copy-on-write such as ZFS where it's useless. This is also said in the documentation [2]. Zero-filling was the default behaviour before the commit. However the documentation doesn't say why we can't just always use wal_init_zero = off, and perhaps get rid of this GUC altogether. In either case the referenced comment is misleading. [1]: https://postgr.es/m/CACPQ5Fo00QR7LNAcd1ZjgoBi4y97%2BK760YABs0vQHH5dLdkkMA%40mail.gmail.com [2]: https://www.postgresql.org/docs/current/runtime-config-wal.html -- Best regards, Aleksander Alekseev
