Re: Experimental patch for inter-page delay in VACUUM

> 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.

I will ask my boss then come back with the result.

> 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?

In the SRA's code, the checkpoint thread opens each file (if it's not
already open of course) which has been written then fsync() it.
--
Tatsuo Ishii