Re: Block-level CRC checks
От | Alvaro Herrera |
---|---|
Тема | Re: Block-level CRC checks |
Дата | |
Msg-id | 20081017152611.GH4218@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Block-level CRC checks (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Block-level CRC checks
Re: Block-level CRC checks Re: Block-level CRC checks Re: Block-level CRC checks Re: Block-level CRC checks |
Список | pgsql-hackers |
So this discussion died with no solution arising to the hint-bit-setting-invalidates-the-CRC problem. 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. 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). -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: