Use of sync() [was Re: Potential Large Performance Gain in WAL synching]

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