Re: Checksums, state of play

On Tue, Mar 6, 2012 at 5:56 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Mon, Mar 05, 2012 at 03:03:18PM +0000, Simon Riggs wrote:
>> To avoid any confusion as to where this proposed feature is now, I'd
>> like to summarise my understanding, make proposals and also request
>> clear feedback on them.
>>
>> Checksums have a number of objections to them outstanding.
>>
>> 1. We don't need them because there will be something better in a
>> later release. I don't think anybody disagrees that a better solution
>> is possible in the future; doubts have been expressed as to what will
>> be required and when that is likely to happen. Opinions differ. We can
>> and should do something now unless there is reason not to.
>
> Obviously, one reason not to do this now is that we are way past time to
> be designing any feature.  As much as I like how it has progressed and
> how it handles pg_upgrade issues, I don't think anyone can state that
> this feature is ready to go, and considering how far we are into the
> last commit-fest, I think we can fairly say this patch has gotten good
> review and return it with feedback.  We can keep discussing it (and I
> just posted some ideas myself), but I don't think we can any longer
> pretend that this is going into Postgres 9.2.

Are you calling time on all patches in this CF, or just this one?

From what you say, this seems to be the reason for your thinking:

On Tue, Mar 6, 2012 at 5:50 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> I think the "turning checksums on/off/on/off" is really a killer
> problem, and obviously many of the actions needed to make it safe make
> the checksum feature itself less useful.

The problem is actually on/off/crash/on in quick succession which is
much less likely.

In the current patch that can be resolved by running a VACUUM to
remove checksums if you want to turn them off completely and safely.
That is easily documented as a procedure for people to follow, like
creating types or setting up replication.

The resolution suggested to that problem is to force a VACUUM to turn
on or turn off. There's very little difference between those two
things other than us forcing the user, which as you point out, being
forced to do that could be worse than the problem we're trying to
solve. From this discussion, ISTM that the "force" route has
sufficient complexity that we could easily make it less robust and
much more likely to receive criticism.

You can break replication by doing on/off/on as well, for example.

It's simply not a killer issue. Not if you have a reasonable grading
of issues. It's a possibility of a usage annoyance, much less annoying
than having an XML type that doesn't actually allow indexes without
knowledge of C, a hash index that doesn't ever recover or an unlogged
table whose data suddenly disappears after a crash, for example.

ISTM pretty reasonable to document the issue clearly, inform people
how it works and let them choose whether to use it or not. Stopping
features from going out because some people might misuse them isn't a
great plan.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services