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]