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

Alfred Perlstein <bright@wintelcom.net>

From: Alfred Perlstein <bright@wintelcom.net>
To: Xu Yifeng <jamexu@telekbird.com.cn>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Mikheev, Vadim" <vmikheev@SECTORBASE.COM>, Bruce Momjian <pgman@candle.pha.pa.us>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2001-03-16T12:45:35Z
Lists: pgsql-hackers
* Xu Yifeng <jamexu@telekbird.com.cn> [010316 01:15] wrote:
> Hello Alfred,
> 
> Friday, March 16, 2001, 3:21:09 PM, you wrote:
> 
> AP> * Xu Yifeng <jamexu@telekbird.com.cn> [010315 22:25] wrote:
> >>
> >> Could anyone consider fork a syncer process to sync data to disk ?
> >> build a shared sync queue, when a daemon process want to do sync after
> >> write() is called, just put a sync request to the queue. this can release
> >> process from blocked on writing as soon as possible. multipile sync
> >> request for one file can be merged when the request is been inserting to
> >> the queue.
> 
> AP> I suggested this about a year ago. :)
> 
> AP> The problem is that you need that process to potentially open and close
> AP> many files over and over.
> 
> AP> I still think it's somewhat of a good idea.
> 
> I am not a DBMS guru.

Hah, same here. :)

> 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.

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