Re: Block-level CRC checks - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Block-level CRC checks
Date
Msg-id 603c8f070912011020v3ac4f003p4532af93cef1973d@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Block-level CRC checks
Re: Block-level CRC checks
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Rewrite GEQO`s gimme_tree function so that it always finds a
Next
From: Simon Riggs
Date:
Subject: Re: Block-level CRC checks