Re: AW: AW: [HACKERS] WAL does not recover gracefully from out-of-dis k-sp ace
Zeugswetter Andreas SB [EMAIL PROTECTED] writes: A short test shows, that opening the file O_SYNC, and thus avoiding fsync() would cut the effective time needed to sync write the xlog more than in half. Of course we would need to buffer = 1 xlog page before write (or commit) to gain the full advantage. prewrite 0 + write and fsync: 60.4 sec sparse file + write with O_SYNC: 37.5 sec no prewrite + write with O_SYNC: 36.8 sec prewrite 0 + write with O_SYNC: 24.0 sec This seems odd. As near as I can tell, O_SYNC is simply a command to do fsync implicitly during each write call. It cannot save any I/O unless I'm missing something significant. Where is the performance difference coming from? The reason I'm inclined to question this is that what we want is not an fsync per write but an fsync per transaction, and we can't easily buffer all of a transaction's XLOG writes... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: AW: AW: [HACKERS] WAL does not recover gracefully from out-of-dis k-sp ace
The reason I'm inclined to question this is that what we want is not an fsync per write but an fsync per transaction, and we can't easily buffer all of a transaction's XLOG writes... WAL keeps records in WAL buffers (wal-buffers parameter may be used to increase # of buffers), so we can make write()-s buffered. Seems that my Solaris has fdatasync, so I'll test different approaches... Vadim ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: AW: AW: [HACKERS] WAL does not recover gracefully from out-of -dis k-sp ace
"Mikheev, Vadim" [EMAIL PROTECTED] writes: Seems that my Solaris has fdatasync, so I'll test different approaches... A Sun guy told me that Solaris does this just the same way that HPUX does it: fsync() scans all kernel buffers for the file, but O_SYNC doesn't, because it knows it only needs to sync the blocks covered by the write(). He didn't say about fdatasync/O_DSYNC but I bet the same difference exists for those two. The Linux 2.4 kernel allegedly is set up so that fsync() is smart enough to only look at dirty buffers, not all the buffers of the file. So the performance tradeoffs would be different there. But on HPUX and probably Solaris, O_DSYNC is likely to be a big win, unless we can find a way to stop the kernel from buffering so much of the WAL files. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
