Tom Lane [EMAIL PROTECTED] writes:
Doug McNaught [EMAIL PROTECTED] writes:
In my understanding, it means all currently dirty blocks in the file
cache are queued to the disk driver. The queued writes will
eventually complete, but not necessarily before sync() returns. I
don't think
[EMAIL PROTECTED] (Tom Lane) writes:
[snip]
On a filesystem that does have that kind of problem, can't you avoid it
just by using O_DSYNC on the WAL files? Then there's no need to call
fsync() at all, except during checkpoints (which actually issue sync()
not fsync(), anyway).
This comment
Mats Lofkvist [EMAIL PROTECTED] writes:
[ mdsync is ugly and not completely reliable ]
Yup, it is. Do you have a better solution?
fsync is not the answer, since the checkpoint process has no way to know
what files may have been touched since the last checkpoint ... and even
if it could find
Tom Lane [EMAIL PROTECTED] writes:
In practice I am not sure there is a problem. The local man page for
sync() says
The writing, although scheduled, is not necessarily complete upon
return from sync.
Now if scheduled means will occur before any subsequently-commanded
write
Doug McNaught [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
In practice I am not sure there is a problem. The local man page for
sync() says
The writing, although scheduled, is not necessarily complete upon
return from sync.
Now if scheduled means will occur before any
