From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enabling Checksums |
Date: | 2012-11-18 20:04:30 |
Message-ID: | 1353269070.10198.97.camel@jdavis-laptop |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2012-11-14 at 17:40 -0800, Jeff Davis wrote:
> I'll do another pass to make sure I update all of the comments, and try
> to self review it.
Updated patches attached (the TLI patch wasn't changed though, only the
main checksums patch).
Changes:
* A lot of cleanup
* More testing
* Added check during pg_upgrade to make sure the checksum settings
match.
* Fixed output of pg_resetxlog to include information about checksums.
* fixed contrib/pageinspect, and included upgrade script for it
* removed code to skip the page hole during the checksum calculation.
We can reconsider if we think performance will be a real problem.
* I added the header bits back in, because we will need them when we
want to support enabling/disabling checksums when the system is online.
I also did quite a bit more testing, although it could use some
performance testing. I'll also probably do another review pass myself,
but I think it's in good shape.
Also, if performance of the checksum calculation itself turns out to be
a problem, we might consider modifying the algorithm to do multiple
bytes at a time.
One purpose of this patch is to establish the on-disk format for
checksums, so we shouldn't defer decisions that would affect that (e.g.
doing checksum calculation in larger chunks, ignoring the page hole, or
using a different scheme for the bits in the header).
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
replace-tli-with-checksums-20121118.patch.gz | application/x-gzip | 7.4 KB |
checksums-20121118.patch.gz | application/x-gzip | 19.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-11-18 20:14:24 | Re: Avoiding overflow in timeout-related calculations |
Previous Message | Tom Lane | 2012-11-18 19:57:51 | Avoiding overflow in timeout-related calculations |