Re: Page-at-a-time Locking Considerations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Page-at-a-time Locking Considerations
Date
Msg-id 16114.1202327887@sss.pgh.pa.us
Whole thread Raw
In response to Re: Page-at-a-time Locking Considerations  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: Page-at-a-time Locking Considerations  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: GSSAPI and V2 protocol
Next
From: Tom Lane
Date:
Subject: Re: Why are we waiting?