Re: Page-at-a-time Locking Considerations

Gregory Stark napsal(a):
> "Bruce Momjian" <bruce(at)momjian(dot)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