> 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