Re: Re[4]: Allowing WAL fsync to be done via O_SYNC
От | Alfred Perlstein |
---|---|
Тема | Re: Re[4]: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 20010316044534.T29888@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re[4]: Allowing WAL fsync to be done via O_SYNC (Xu Yifeng <jamexu@telekbird.com.cn>) |
Ответы |
Re: Re[4]: Allowing WAL fsync to be done via O_SYNC
|
Список | 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]
В списке pgsql-hackers по дате отправления: