[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 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
[EMAIL PROTECTED]
(*) See for example
http://groups.google.com/groups?th=bfc8a0dc5373ed6e
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
