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 47AACF59.70802@sun.com
Whole thread Raw
In response to Re: Page-at-a-time Locking Considerations  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark napsal(a):
> "Bruce Momjian" <bruce@momjian.us> writes:
> 
>>>>> 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.
> 
> Another possibility for the CLOG would be having two on-disk copies of it. One
> temporary file which would serve purely as the filesystem swap space for the
> in-memory pages and would be synced and/or flushed from memory based purely on
> memory pressure. The second would be the persistent store which we would write
> with copies of pages to when it was time to sync them. On boot we would throw
> away the old filesystem back and copy the persistent store.

The idea to have two CLOG files copy is also good for better reliability. CLOG 
is currently single point of failure. One bad block causes a big data lost.

    Zdenek


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: build environment: a different makefile
Next
From: Dimitri Fontaine
Date:
Subject: Re: PostgreSQL 8.4 development plan