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 11:09:53 |
Message-ID: | CA+U5nMKGYB5z7NAbeyUn0w7M8Aq6Bh5ai5bQ-ocESsr_kCPT8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 7, 2012 at 10:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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?
And of course, as soon as I wrote that I thought of the problem. We
mustn't make a write that hasn't been covered by a FPW, so we must
know ahead of time whether to WAL log hints or not. We can't simply
turn it on/off any longer, now that we have to WAL log hint bits also.
So thanks for making me think of that.
We *could* make it turn on/off at each checkpoint, but its easier just
to say that it can be turned on/off at server start.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Satoshi Nagayasu / Uptime Technologies, LLC. | 2012-01-07 14:02:37 | Re: LWLOCK_STATS |
Previous Message | Simon Riggs | 2012-01-07 10:55:19 | Re: 16-bit page checksums for 9.2 |