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