"Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com> wrote:
> > If you use Linux, it has very unpleased behavior in fsync(); It locks all
> > metadata of the file being fsync-ed. We have to wait for the completion of
> > fsync when we do read(), write(), and even lseek().
>
> Oh, really, what an evil fsync is! Yes, I sometimes saw a backend
> waiting for lseek() to complete when it committed. But why does the
> backend which is syncing WAL/pg_control have to wait for syncing the
> data file? They are, not to mention, different files, and WAL and
> data files are stored on separate disks.
Backends call lseek() in planning, so they have to wait fsync() to
the table that they will access. Even if all of data in the file is in
the cache, lseek() conflict with fsync(). You can see a lot of backends
are waiting in planning phase in checkpoints, not executing phase.
> > it's not difficult at all to insert sleeps between fsync()s.
> Can we say "our approach helps our
> environments, but it won't help you. The kernel VM settings may help
> you. Good luck!"?
I didn't say such a thing at all.
There are several opinions in the discussion: 1. High bgwriter setting is enough! 2. Change your OS :-) 3. Use O_SYNC
orO_DIRECT, but very poor performance. 4. We may settle for single fsync(), but not many fsync()s in a short time.
I just suggested 4.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center