Re: Idea for fixing the Windows fsync problem

From: "Tom Lane" <tgl@sss.pgh.pa.us>
> It's still not 100% bulletproof, because it's possible that some
other
> backend is holding an open file in the database as a consequence of
> having had to dump some shared buffer for itself, but that should be
> pretty darn rare if the bgwriter is getting its job done.

I've understood that you are talking about the case where backends
have to evict dirty buffers containing data of a database they are not
connected to.  The problem is that the backends don't close the data
file after writing dirty buffers.
Then, how about making the backends close the data files?  Concretely,
in FlushBuffer() in src/backend/storage/buffer/bufmgr.c, call
SmgrClose() after SmgrWrite() like this:

--------------------------------------------------
if (reln passed to FlushBuffer() was NULL &&   reln->smgr_rnode.dbNode != my database's oid(where is this
stored?)   SmgrClose(reln);
}
--------------------------------------------------


Or, to make the intention clearer, it may be better to add calls to
SmgrOpen() and SmgrClose() in succession after FlushBuffer() in
BufferAlloc().


BTW, fsync() is causing trouble here in addition to load-distributed
checkpoint that Itagaki-san has been addressing, isn't it?  If fsync
were eliminated by using O_SYNC as commercial databases, Tom-san
didn't have to make efforts to solve this problem.