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

From Zdenek Kotala
Subject Re: Page-at-a-time Locking Considerations
Date
Msg-id 47AA2174.3060409@sun.com
Whole thread Raw
In response to Re: Page-at-a-time Locking Considerations  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Page-at-a-time Locking Considerations  (Gregory Stark <stark@enterprisedb.com>)
Re: Page-at-a-time Locking Considerations  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.
    Zdenek


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: PostgreSQL 8.4 development plan
Next
From: Dimitri Fontaine
Date:
Subject: Re: PostgreSQL 8.4 development plan