Re: Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* Bruce Momjian <[EMAIL PROTECTED]> [010316 07:11] 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. > > > > 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. > > I like the idea too, but people want the transaction to return COMMIT > only after data has been fsync'ed so I don't see a big win. This isn't simply handing off the sync to this other process, it requires an ack from the syncer before returning 'COMMIT'. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC
> > 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. I like the idea too, but people want the transaction to return COMMIT only after data has been fsync'ed so I don't see a big win. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* Xu Yifeng <[EMAIL PROTECTED]> [010315 22:25] wrote: > Hello Tom, > > Friday, March 16, 2001, 6:54:22 AM, you wrote: > > TL> Alfred Perlstein <[EMAIL PROTECTED]> 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 - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re[2]: [HACKERS] Allowing WAL fsync to be done via O_SYNC
Hello Tom, Friday, March 16, 2001, 6:54:22 AM, you wrote: TL> Alfred Perlstein <[EMAIL PROTECTED]> 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. -- Regards, Xu Yifeng ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
