Re: Checksums, state of play - Mailing list pgsql-hackers

On Tue, Mar 06, 2012 at 07:09:23PM +0000, Simon Riggs wrote:
> On Tue, Mar 6, 2012 at 5:56 PM, Bruce Momjian <bruce@momjian.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:

I am calling time on any CF patch that requires redesign.

> > 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.

True.

> 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.

The feature is no where near complete, and we should not be designing
features at this stage.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +