Re: Re[4]: Allowing WAL fsync to be done via O_SYNC

* Tom Lane <tgl@sss.pgh.pa.us> [010316 08:16] wrote:
> Alfred Perlstein <bright@wintelcom.net> writes:
> >> couldn't the syncer process cache opened files? is there any problem I
> >> didn't consider ?
> 
> > 1) IPC latency, the amount of time it takes to call fsync will
> >    increase by at least two context switches.
> 
> > 2) a working set (number of files needed to be fsync'd) that
> >    is larger than the amount of files you wish to keep open.
> 
> These days we're really only interested in fsync'ing the current WAL
> log file, so working set doesn't seem like a problem anymore.  However
> context-switch latency is likely to be a big problem.  One thing we'd
> definitely need before considering this is to replace the existing
> spinlock mechanism with something more efficient.

What sort of problems are you seeing with the spinlock code?

> Vadim has designed the WAL stuff in such a way that a separate
> writer/syncer process would be easy to add; in fact it's almost that way
> already, in that any backend can write or sync data that's been added
> to the queue by any other backend.  The question is whether it'd
> actually buy anything to have another process.  Good stuff to experiment
> with for 7.2.

The delayed/coallecesed (sp?) fsync looked interesting.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]