Re: SRA Win32 sync() code
От | Bruce Momjian |
---|---|
Тема | Re: SRA Win32 sync() code |
Дата | |
Msg-id | 200311300331.hAU3V3p06824@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: SRA Win32 sync() code ("Merlin Moncure" <merlin.moncure@rcsonline.com>) |
Список | pgsql-hackers-win32 |
Merlin Moncure wrote: > 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. The problem is that fsync on commit of all open files would cause poor performance. -- 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
В списке pgsql-hackers-win32 по дате отправления: