My experience with windows backend work is that you have to turn off all
buffering and implement your own write cache of sorts.  Flushing is not
the only reason: heavy buffering of files (the default behavior) also
tends to thrash the server, because the cache does not always release
memory properly.

Likewise, with memory for maximum results you have to go straight to
VirtualAlloc() and avoid using the C run time to do any persistent
memory allocation.  Memory pages get mapped to file pages and all file
reads/writes are on sector boundaries.  Generally, it's a nightmare.

> -----Original Message-----
> From: Dave Page [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 06, 2003 11:02 AM
> To: Tatsuo Ishii
> Subject: Re: [HACKERS] Win32 Powerfail testing
> > -----Original Message-----
> > From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
> > Sent: 06 March 2003 15:17
> > To: Dave Page
> > Subject: Re: [HACKERS] Win32 Powerfail testing
> >
> > I'm sure FlushFileBuffers() is usesless for files opend with
> > open() too.
> >
> > As I said in the previlus mails, open()+_commit() does the
> > right job with the transaction log files. So probably I think
> > I should stick with open()+_commit() approach for ordinary
> > table/index files too.
> Oh, I didn't see that message. So it's either:
> open() + _commit()
> Or
> CreateFile() + FlushFileBuffers()
> Magnus also mentioned using FILE_FLAG_NO_BUFFERING or
> FILE_FLAG_WRITE_THROUGH with CreateFile(). I was concerned about the
> additional complexity with FILE_FLAG_NO_BUFFERING, but
> FILE_FLAG_WRITE_THROUGH sounds like it might do the job, if a little
> sub-optimally.
> Is there really no way of allowing a decent write cache, but then
> able to guarantee a flush at the required time? Sounds a little cuckoo
> to me but then it is Microsoft...
> Anyhoo, it sounds like open() and _commit is this best choice as you
> say.
> Regards, Dave.
> ---------------------------(end of
> TIP 4: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to