Re: [PATCHES] SRA Win32 sync() code

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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.

[ Discussion moved to hackers/win32.]

I was thinking about sync() --- one of its problems is that is schedules
writes to disk but returns before it is completed. If we do sync(),
then open, write, fsync, close a file, aren't we then pretty sure all
the scheduled sync writes have completed too? I know SCSI has tagged
queueing, but I figured creating a new file and writing/fsync would come
after the sync writes.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073