Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Block-level CRC checks
Дата
Msg-id 603c8f070912011020v3ac4f003p4532af93cef1973d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: Block-level CRC checks
Re: Block-level CRC checks
Список pgsql-hackers
On Tue, Dec 1, 2009 at 1:02 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> The hard core reality is this. *IF* it is one of the goals of this
> project to insure that the software can be safely, effectively, and
> responsibly operated in a manner that is acceptable to C* level people
> in a Fortune level company then we *must* solve this problem.
>
> If it is not the goal of the project, leave it to EDB/CMD/2ndQuandrant
> to fork it because it will eventually happen. Our customers are
> demanding these features.

OK, and when you fork it, how do you plan to implement it?  The
problem AFAICS is not that anyone hugely dislikes the feature; it's
that nobody is really clear on how to implement it in a way that's
actually useful.

So far the only somewhat reasonable suggestions I've seen seem to be:

1. WAL-log setting the hint bits.  If you don't like the resulting
performance, shut off the feature.

2. Rearrange the page so that all the hint bits are in the first 512
bytes along with the CRC, so that there can be no torn pages.  AFAICS,
no one has rendered judgment on whether this is a feasible solution.

Does $COMPETITOR offer this feature?

...Robert


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Block-level CRC checks