Re: Re[2]: 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-16T07:21:09Z
Lists: 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]