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.

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073