From: | Alfred Perlstein <bright(at)wintelcom(dot)net> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
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:43:24 |
Message-ID: | 20010316074324.X29888@fw.wintelcom.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> [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 - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
From | Date | Subject | |
---|---|---|---|
Next Message | Ken Hirsch | 2001-03-16 15:44:49 | Re: Allowing WAL fsync to be done via O_SYNC |
Previous Message | Larry Rosenman | 2001-03-16 15:38:43 | Re: Re: AW: Allowing WAL fsync to be done via O_SYNC |