Re: Page-at-a-time Locking Considerations

Zdenek Kotala wrote:
> Tom Lane wrote:
> > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> >> Tom Lane wrote:
> >>> If you only got 2% out of it, it's not even worth thinking about how to
> >>> fix the serious bugs that approach would create (primarily, lack of
> >>> control over when pages can get flushed to disk).
> > 
> >> You can flush a pages by msync() function which writes dirty pages on 
> >> disk. I don't see any other problem.
> > 
> > Then you need to learn more.  The side of the problem that is hard to
> > fix is that sometimes we need to prevent pages from being flushed to
> > disk until some other data (typically WAL entries) has reached disk.
> > With mmap'd data we have no control over early writes.
> 
> I see. Thanks for explanation.

This is mentioned in the TODO list:

* Consider mmap()'ing files into a backend?
 Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping.  Extending the
filealso causes mapping problems that might require mapping only individual pages, leading to thousands of mappings.
Anotherproblem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk
beforeWAL is written.
 

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +