Re: Checksums, state of play

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Checksums, state of play
Date: 2012-03-06 17:56:13
Message-ID: 20120306175613.GB1347@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 2. Turning checksums on/off/on/off in rapid succession can cause false
> positive reports of checksum failure if crashes occur and are ignored.
> That may lead to the feature and PostgreSQL being held in disrepute.
> This can be resolved, if desired, by having having a two-stage
> enabling process where we must issue a command that scans every block
> in the database before checksum checking begins. VACUUM is easily
> modified to the task, we just need to agree that is suitable and agree
> syntax.
> A suggestion is VACUUM ENABLE CHECKSUMS; others are possible.

There is no question that if this feature is done badly, it will make
Postgres look bad, and no one wants that. As nice as this features is,
making Postgres look bad can't justify it as it currently sits.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-03-06 17:57:30 Re: elegant and effective way for running jobs inside a database
Previous Message Bruce Momjian 2012-03-06 17:50:24 Re: Checksums, state of play