Re: Re[2]: Allowing WAL fsync to be done via O_SYNC
От | Alfred Perlstein |
---|---|
Тема | Re: Re[2]: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 20010315232108.S29888@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re[2]: Allowing WAL fsync to be done via O_SYNC (Xu Yifeng <jamexu@telekbird.com.cn>) |
Ответы |
Re[4]: Allowing WAL fsync to be done via O_SYNC
Re: Re[2]: Allowing WAL fsync to be done via O_SYNC |
Список | pgsql-hackers |
* Xu Yifeng <jamexu@telekbird.com.cn> [010315 22:25] wrote: > Hello Tom, > > Friday, March 16, 2001, 6:54:22 AM, you wrote: > > TL> Alfred Perlstein <bright@wintelcom.net> writes: > >> How many files need to be fsync'd? > > TL> Only one. > > >> If it's more than one, what might work is using mmap() to map the > >> files in adjacent areas, then calling msync() on the entire range, > >> this would allow you to batch fsync the data. > > TL> Interesting thought, but mmap to a prespecified address is most > TL> definitely not portable, whether or not you want to assume that > TL> plain mmap is ... > > TL> regards, tom lane > > 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. I suggested this about a year ago. :) The problem is that you need that process to potentially open and close many files over and over. I still think it's somewhat of a good idea. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
В списке pgsql-hackers по дате отправления: