tgl@sss.pgh.pa.us (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 on using sync() instead of fsync() makes me slightly
worried since sync() doesn't in any way guarantee that all data is
written immediately. E.g. on *BSD with softupdates, it doesn't even
guarantee that data is written within some deterministic time as
far as I know (*).
With a quick check of the code I found
/** mdsync() -- Sync storage.**/
int
mdsync()
{sync();if (IsUnderPostmaster) sleep(2);sync();return SM_SUCCESS;
}
which is ugly (imho) even if sync() starts an immediate and complete
file system flush (which I don't think it does with softupdates).
It seems to be used only by
/* ------------------------------------------------* FlushBufferPool** Flush all dirty blocks in buffer pool to disk*
atthe checkpoint time* ------------------------------------------------*/
void
FlushBufferPool(void)
{BufferSync();smgrsync(); /* calls mdsync() */
}
so the question that remains is what kinds of guarantees
FlushBufferPool() really expects and needs from smgrsync() ?
If smgrsync() is called to make up for lack of fsync() calls
in BufferSync(), I'm getting really worried :-)
_
Mats Lofkvist
mal@algonet.se
(*) See for example http://groups.google.com/groups?th=bfc8a0dc5373ed6e
