From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sync_file_range() |
Date: | 2006-06-19 11:29:15 |
Message-ID: | 1150716555.2691.1132.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2006-06-19 at 15:32 +0800, Qingqing Zhou wrote:
> "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> wrote
> >
> >
> > I'm interested in it, with which we could improve responsiveness during
> > checkpoints. Though it is Linux specific system call, but we could use
> > the combination of mmap() and msync() instead of it; I mean we can use
> > mmap only to flush dirty pages, not to read or write pages.
> >
>
> Can you specify details? As the TODO item inidcates, if we mmap data file, a
> serious problem is that we don't know when the data pages hit the disks --
> so that we may voilate the WAL rule.
Can't see where we'd use it.
We fsync the xlog at transaction commit, so only the leading edge needs
to be synced - would the call help there? Presumably the OS can already
locate all blocks associated with a particular file fairly quickly
without doing a full cache scan.
Other files are fsynced at checkpoint - always all dirty blocks in the
whole file.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-19 12:08:46 | Re: regresssion script hole |
Previous Message | ITAGAKI Takahiro | 2006-06-19 10:33:44 | Re: sync_file_range() |