Hi. Em qua., 15 de jan. de 2025 às 06:12, Andy Fan <zhihuifan1...@163.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
