Re: Page-at-a-time Locking Considerations

Поиск
Список
Период
Сортировка
От Zdenek Kotala
Тема Re: Page-at-a-time Locking Considerations
Дата
Msg-id 47AACF59.70802@sun.com
обсуждение исходный текст
Ответ на Re: Page-at-a-time Locking Considerations  (Gregory Stark <stark@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: build environment: a different makefile
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: PostgreSQL 8.4 development plan