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

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010316 08:16] wrote:
> Alfred Perlstein <bright(at)wintelcom(dot)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(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]