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
 * at the 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