Re: Re[2]: Allowing WAL fsync to be done via O_SYNC - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: Re[2]: Allowing WAL fsync to be done via O_SYNC
Date
Msg-id 20010315232108.S29888@fw.wintelcom.net
Whole thread Raw
In response to Re[2]: Allowing WAL fsync to be done via O_SYNC  (Xu Yifeng <jamexu@telekbird.com.cn>)
Responses Re[4]: Allowing WAL fsync to be done via O_SYNC  (Xu Yifeng <jamexu@telekbird.com.cn>)
Re: Re[2]: Allowing WAL fsync to be done via O_SYNC  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Xu Yifeng
Date:
Subject: Re[2]: Allowing WAL fsync to be done via O_SYNC
Next
From: Xu Yifeng
Date:
Subject: Re[4]: Allowing WAL fsync to be done via O_SYNC