Re: Page-at-a-time Locking Considerations

Zdenek Kotala wrote:
> Tom Lane wrote:
> > Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)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 file also causes
mapping problems that might require mapping only individual pages,
leading to thousands of mappings. Another problem is that there is no
way to _prevent_ I/O to disk from the dirty shared buffers so changes
could hit disk before WAL is written.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +