Re: [pgsql-hackers-win32] [PATCHES] SRA Win32 sync() code

Tom Lane wrote:
> 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.

[ 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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073