Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Jonah H. Harris
Тема Re: Block-level CRC checks
Дата
Msg-id 36e682920810170842w1ff3e521ncdf691e65c378f4c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Block-level CRC checks  (Greg Stark <greg.stark@enterprisedb.com>)
Список pgsql-hackers
On Fri, Oct 17, 2008 at 11:26 AM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> So this discussion died with no solution arising to the
> hint-bit-setting-invalidates-the-CRC problem.

I've been busy.

> Apparently the only solution in sight is to WAL-log hint bits.  Simon
> opines it would be horrible from a performance standpoint to WAL-log
> every hint bit set, and I think we all agree with that.  So we need to
> find an alternative mechanism to WAL log hint bits.

Agreed.

> I thought about causing a process that's about to write a page check a
> flag that says "this page has been dirtied by someone who didn't bother
> to generate WAL".  If the flag is set, then the writer process is forced
> to write a WAL record containing all hint bits in the page, and only
> then it is allowed to write the page (and thus calculate the new CRC).

Interesting idea... let me ponder it for a bit.

-- 
Jonah H. Harris, Senior DBA
myYearbook.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Block-level CRC checks
Следующее
От: Andrew Chernow
Дата:
Сообщение: Re: 8.3 .4 + Vista + MingW + initdb = ACCESS_DENIED