From: | Markus Wanner <markus(at)bluegap(dot)ch> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Greg Smith <greg(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enabling Checksums |
Date: | 2012-11-12 19:44:02 |
Message-ID: | 50A15182.8080802@bluegap.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff,
On 11/12/2012 06:52 PM, Jeff Davis wrote:
> OK, so here's my proposal for a first patch (changes from Simon's
> patch):
>
> * Add a flag to the postgres executable indicating that it should use
> checksums on everything. This would only be valid if bootstrap mode is
> also specified.
> * Add a multi-state checksums flag in pg_control, that would have
> three states: OFF, ENABLING, and ON. It would only be set to ON during
> bootstrap, and in this first patch, it would not be possible to set
> ENABLING.
> * Remove GUC and use this checksums flag everywhere.
> * Use the TLI field rather than the version field of the page header.
> * Incorporate page number into checksum calculation (already done).
>
> Does this satisfy the requirements for a first step? Does it interfere
> with potential future work?
As described before in this thread, I think we might be able to do
without the "has checksum"-bit, as yet another simplification. But I
don't object to adding it, either.
> It's slightly better than that. It's more like: "we can tell you if any
> of your data gets corrupted after transaction X". If old data is
> corrupted before transaction X, then there's nothing we can do. But if
> it's corrupted after transaction X (even if it's old data), the
> checksums should catch it.
I (mis?)read that as Greg referring to the intermediate (enabling)
state, where pages with old data may or may not have a checksum, yet. So
I think it was an argument against staying in that state any longer than
necessary.
Regards
Markus Wanner
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-11-12 19:59:21 | Re: Inadequate thought about buffer locking during hot standby replay |
Previous Message | Simon Riggs | 2012-11-12 19:40:53 | Re: Inadequate thought about buffer locking during hot standby replay |