Skip site navigation (1) Skip section navigation (2)

Re: SRA Win32 sync() code

From: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "PostgreSQL Win32 port list" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: SRA Win32 sync() code
Date: 2003-11-18 13:12:59
Message-ID: 303E00EBDD07B943924382E153890E5434AA10@cuthbert.rcsinc.local (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
Bruce Momjian wrote:
> Here is the SRA sync() code for Win32.  As you might know, fsync on
> Win32 is _commit, and sync() is _flushall.  However, _flushall only
> flushes only _open_ kernel buffers, not dirty buffers that have been
> closed.  Therefore, on Win32, during checkpoint, you have to open,
> fsync(_commit), close all file that have been modified since the
> previous checkpoint.

That is not quite correct.  flushall() flushes all open file streams,
not open file 'handles' i.e. array references to _osfile[] returned by
_open().  flushall() is an aggregate fflush() command().  Note that this
is as implemented by Microsoft C runtime, not necessarily MinGW.  So,
when compiled with the ms C libraries, _flushall is useless.

A _handle based flushall routine would have to loop over the _osfile
array and commit file handles, or track them externally as SRA did.

What about rewriting the close routine to call FlushFileBuffers before
closing the file?  Would this break anything?

> Not sure how we are going to do this in Win32, but somehow we will
have
> to record all open files between checkpoints in an area that the
> checkpoint process can read during a checkpoint.

Iff the file handles can be reliably commited on closure this would not
be necessary.  The C runtime already keeps track of open files.

Merlin


Responses

pgsql-hackers-win32 by date

Next:From: Claudio NatoliDate: 2003-11-18 15:36:35
Subject: fork/exe [was Not 7.5, but 8.0 ?]
Previous:From: Bruce MomjianDate: 2003-11-17 15:34:42
Subject: Re: [PATCHES] SRA Win32 sync() code

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group