Shridhar Daithankar wrote:
> On Friday 14 November 2003 03:05, Jan Wieck wrote:
> > For sure the sync() needs to be replaced by the discussed fsync() of
> > recently written files. And I think the algorithm how much and how often
> > to flush can be significantly improved. But after all, this does not
> > change the real checkpointing at all, and the general framework having a
> > separate process is what we probably want.
>
> Having fsync for regular data files and sync for WAL segment a comfortable
> compramise? Or this is going to use fsync for all of them.
I think we still need sync() for WAL because sometimes backends are
going to have to write their own buffers, and we don't want them using
fsync or it will be very slow.
> IMO, with fsync, we tell kernel that you can write this buffer. It may or may
> not write it immediately, unless it is hard sync.
>
> Since postgresql can afford lazy writes for data files, I think this could
> work.
fsync() doesn't return until the data is on the disk. It doesn't
schedule the write then return, as far as I know. sync() does schedule
the writes, I think, which can be bad, but we delay a little to wait for
it to complete.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073