From: "Tom Lane" <[EMAIL PROTECTED]> > 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. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster