I'm wondering about the intent of this snippet in xlog.c: fd = BasicOpenFile(tpath, O_RDWR | O_CREAT | O_EXCL | PG_BINARY, S_IRUSR | S_IWUSR); if (fd < 0) elog(STOP, "InitCreate(logfile %u seg %u) failed: %m", logId, logSeg); if (lseek(fd, XLogSegSize - 1, SEEK_SET) != (off_t) (XLogSegSize - 1)) elog(STOP, "lseek(logfile %u seg %u) failed: %m", logId, logSeg); if (write(fd, "", 1) != 1) elog(STOP, "write(logfile %u seg %u) failed: %m", logId, logSeg); if (fsync(fd) != 0) elog(STOP, "fsync(logfile %u seg %u) failed: %m", logId, logSeg); if (lseek(fd, 0, SEEK_SET) < 0) elog(STOP, "lseek(logfile %u seg %u off %u) failed: %m", log, seg, 0); close(fd); If the idea here is to force XLogSegSize bytes of disk space to be allocated, it's a loser. Most Unix file systems that I know about will treat the file as containing a "hole", and only allocate the single block in which data has actually been written. The fact that 'ls' shows the file as 16MB is a user-interface artifact of ls; du will tell you the grim truth: $ initdb ... $ ls -l data/pg_xlog total 328 -rw------- 1 postgres users 16777216 Nov 27 00:44 0000000000000000 $ du data/pg_xlog/0000000000000000 328 data/pg_xlog/0000000000000000 I don't know whether you consider it important to force the logfile to be fully allocated before you start using it; but if you do, the above code will not get the job done. regards, tom lane