| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Alfred Perlstein <bright(at)wintelcom(dot)net> |
| Cc: | Xu Yifeng <jamexu(at)telekbird(dot)com(dot)cn>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re[2]: Allowing WAL fsync to be done via O_SYNC |
| Date: | 2001-03-16 15:11:30 |
| Message-ID: | 200103161511.KAA08993@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2001-03-16 15:11:51 | Re: AW: Allowing WAL fsync to be done via O_SYNC |
| Previous Message | Zeugswetter Andreas SB | 2001-03-16 15:02:38 | AW: Allowing WAL fsync to be done via O_SYNC |