Re: [HACKERS] TODO item

> Ok, here's a nifty idea, a slave process called pgsyncer.  
> 
> At the end of a transaction a backend asks the syncer to fsync all files.
> 
> Now here's the cool part, this avoids the non-portability of the Linux
> sync() problem and at the same time restricts the syncing to postgresql
> and reduces 'cross-fsync' issues.
> 
> Imagine:
> 
> postgresql has 3 files open (a, b, c), so will the syncer.
> backend 1 completes a request, communicates to the syncer that a flush
>   is needed.
> syncer starts by fsync'ing 'a'
> backend 2 completes a request, communicates to the syncer
> syncer continues with 'b' then 'c'
> syncer responds to backend 1 that it's safe to proceed.
> syncer fsyncs 'a' again
> syncer responds to backend 2 that it's all completed.
> 
> effectively the fsync of 'b' and 'c' have been batched.
> 
> It's just an elevator algorithm, perhaps this can be done without
> a seperate slave process?

If you go to the hackers archive, you will see an implementation under
subject "Bufferd loggins/pg_log" dated November 1997.  We have gone over
2 years without this option, and it is going to be even longer before it
is available via WAL.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026