Jan Wieck wrote: > What bothers me a little is that you keep telling us that you have all > that great code from SRA. Do you have any idea when they intend to share > this with us and contribute the stuff? I mean at least some pieces > maybe? You personally got all the code from NuSphere AKA PeerDirect even > weeks before it got released. Did any PostgreSQL developer other than > you ever look at the SRA code?
I can get the open/fsync/write/close patch from SRA released, I think. Let me ask them now. Tom has seen the Win32 tarball (with SRA's approval) because he wanted to research if threading was something we should pursue. I haven't heard a report back from him yet. If you would like to see the tarball, I can ask them. Agreed, I got the PeerDirect/Nusphere code very early and it was a help. I am sure I can get some of it released. I haven't pursued the sync Win32 patch because it is based on a threaded backend model, so it is different from how it need to be done in a process model (all shared file descriptors). However, I will need to get approval in the end anyway for Win32 because I need that Win32-specific part anyway. I just looked at the sync() call in the code and it just did _flushall: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__flushall.asp I can share this because I know it was discussed when someone (SRA?) realized _commit() didn't force all buffers to disk. In fact, _commit is fsync(). I think the only question was whether _flushall() fsync file descriptors that have been closed. Perhaps SRA keeps the file descriptors open until after the checkpoint, or does it fsync closed files with dirty buffers. Tatsuo? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings