Re: Use of sync() [was Re: Potential Large Performance Gain in WAL synching]

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Doug McNaught <doug(at)wireboard(dot)com> writes:

> > In my understanding, it means "all currently dirty blocks in the file
> > cache are queued to the disk driver". The queued writes will
> > eventually complete, but not necessarily before sync() returns. I
> > don't think subsequent write()s will block, unless the system is low
> > on buffers and has to wait until dirty blocks are freed by the driver.
>
> We don't need later write()s to block. We only need them to not hit
> disk before the sync-queued writes hit disk. So I guess the question
> boils down to what "queued to the disk driver" means --- has the order
> of writes been determined at that point?

It's certainy possible that new write(s) get put into the queue
alongside old ones--I think the Linux block layer tries to do this
when it can, for one. According to the manpage, Linux used to wait
until everything was written to return from sync(), though I don't
*think* it does anymore. But that's not mandated by the specs.

So I don't think we can rely on such behavior (not reordering writes
across a sync()), though it will probably happen in practice a lot of
the time. AFAIK there isn't anything better than sync() + sleep() as
far as the specs go. Yes, it kinda sucks. ;)

-Doug