| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Markus Wanner <markus(at)bluegap(dot)ch> |
| Cc: | Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Enabling Checksums |
| Date: | 2012-11-09 18:53:38 |
| Message-ID: | 1352487218.6292.78.camel@jdavis-laptop |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2012-11-09 at 15:42 +0100, Markus Wanner wrote:
> On 11/09/2012 06:18 AM, Jesper Krogh wrote:
> > I would definately stuff our system in state = 2 in your
> > description if it was available.
>
> Hm.. that's an interesting statement.
>
> What's probably worst when switching from OFF to ON is the VACUUM run
> that needs to touch every page (provided you haven't ever turned
> checksumming on before). Maybe you want to save that step and still get
> the additional safety for newly dirtied pages, right?
>
> A use case worth supporting?
One problem is telling which pages are protected and which aren't. We
can have a couple bits in the header indicating that a checksum is
present, but it's a little disappointing to have only a few bits
protecting a 16-bit checksum.
Also, I think that people will want to have a way to protect their old
data somehow.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2012-11-09 18:58:57 | Re: Enabling Checksums |
| Previous Message | Jeff Janes | 2012-11-09 18:50:17 | Re: Further pg_upgrade analysis for many tables |