From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WIP checksums patch |
Date: | 2012-11-09 23:14:26 |
Message-ID: | 1352502866.26644.15.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2012-11-05 at 12:19 -0500, Robert Haas wrote:
> Yeah. I definitely think that we could shed an enormous amount of
> complexity by deciding that this is, for now, an option that can only
> be selected at initdb time. That would remove approximately 85% of
> everything I've ever disliked about this patch - without, I think,
> precluding the possibility of improving things later.
That's certainly true, but it introduces one large problem: upgrading
would not work, which (in the past few releases) we've treated as a
major showstopper for many features.
If there is really no other good way to do it, then that might be
reasonable. But it seems within grasp to at least offer an offline way
to set checksums.
> It also occurred to me that another way to reduce the scope of this
> change would be to have a first version that does CRCs only for SLRU
> pages. That would be useful for verifying the integrity of some of
> our most critical data (pg_clog) and be a useful building block toward
> a more complete implementation.
That also breaks upgrade, right?
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-11-09 23:18:53 | Re: Further pg_upgrade analysis for many tables |
Previous Message | Jeff Davis | 2012-11-09 23:08:48 | Re: Enabling Checksums |