On Sat, Jun 12, 2004 at 04:00:46PM -0400, Tom Lane wrote:
> There was talk earlier of providing an option to issue sync() before
> starting the loop that issues fsync() against each file we've written
> since the last checkpoint. The idea was that the sync() would cue the
> kernel to schedule I/O for all currently dirty buffers in the most
> efficient order, and then the fsync()s would merely ensure that Postgres
> waits until the I/O it needs is done. This should be optional since it
<snip>
Not a good idea on some systems. From the linux sync(2) manpage:
BUGS
According to the standard specification (e.g., SVID), sync()
schedules the writes, but may return before the actual writing
is done. However, since version 1.3.20 Linux does actually
wait. (This still does not guaran- tee data integrity: modern
disks have large caches.)
So your fsyncs become no-ops instead. And I don't think we need a
discussion on whether this behaviour is correct or not, this is the way
it is, I don't know why.
I wonder if any other systems works this way...
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
