| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, david(at)fetter(dot)org, aidan(at)highrise(dot)ca, stark(at)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 16-bit page checksums for 9.2 |
| Date: | 2012-01-07 10:55:19 |
| Message-ID: | CA+U5nMJWoH+tZJ01CvFs9aqnziMCzCvboj4uA75dGVEZOg0SQQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 7, 2012 at 10:26 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> There needs to be a well-documented way of turning it on/off. In particular,
> from off to on.
There is.... in the patch.
The checksum field is optional, as is the parameter.
If page_checksums is on, we write a checksum and it is correct. We
also validate any checksums we see.
If page_checksums is off we clear the checksum on write, so an
incorrect checksum is never written.
So there isn't any problem with there being incorrect checksums on
blocks and you can turn the parameter on and off as often and as
easily as you want. I think it can be USERSET but I wouldn't want to
encourage users to see turning it off as a performance tuning feature.
If the admin turns it on for the server, its on, so its SIGHUP.
Any holes in that I haven't noticed?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-01-07 11:09:53 | Re: 16-bit page checksums for 9.2 |
| Previous Message | Simon Riggs | 2012-01-07 10:29:43 | Re: Intermittent regression test failures from index-only plan changes |