Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Where am I wrong?
I don't think any of this is relevant. There are a certain number of
blocks we have to get down to disk before we can declare a transaction
committed, and there are a certain number that we have to get down to
disk before we can declare a checkpoint complete. You are focusing too
much on the question of whether a particular process performs an fsync
operation, and ignoring the fact that ultimately it's got to wait for
I/O to complete --- directly or indirectly. If it blocks waiting for
some other process to declare a buffer clean, rather than writing for
itself, what's the difference?
Sure, fsync serializes the particular process that's doing it, but we
can deal with that by spreading the fsyncs across multiple processes,
and trying to ensure that they are mostly background processes rather
than foreground ones.
I don't claim that immediate-fsync-on-write is the only answer, but
I cannot follow your reasoning for dimissing it out of hand ... and I
certainly cannot buy *any* logic that says that sync() is a good answer
to any of these issues. AFAICS sync() means that we abandon
responsibility.
> Do we know that having the background writer fsync a file that was
> written by a backend cause all the data to fsync? I think I could write
> a program to test this by timing each of these tests:
That might prove something about the particular platform you tested it
on; but it would not speak to the real problem, which is what we can
assume is true on every platform...
regards, tom lane