On 1/23/17 12:03 PM, Greg Stark wrote:
> On Jan 22, 2017 11:13 AM, "Magnus Hagander" <magnus@hagander.net
> <mailto:magnus@hagander.net>> wrote:
>
>
> Yes, this means the entire db will end up in the transaction log
> since everything is rewritten. That's not great, but for a lot of
> people that will be a trade they're willing to make since it's a
> one-time thing. Yes, this background process might take days or
> weeks - that's OK as long as it happens online.
>
>
> I'm not sure that's actually necessary. You could just log a wal record
> saying "checksum this block" and if it gets replayed then recalculate
> the checksum on that block again. This record could be exempt from the
> usual rules for having a fpw.
>
> There's no danger of torn pages from the checksum alone. The danger
> would be if some other operation does dirty that page then your need to
> know that the page is in this weird in between state where it's dirty
> but not yet had a fpw written.
>
> I'm not sure whether it's worth the infrastructure to have such a state
> just for this or not. On the other hand it sounds like something that
> would be useful.
I'm a bit concerned about how much fancy we're trying to put into a
first pass at this.
I think it's reasonable to require a fairly significant amount of effort
on the part of an admin to enable checksums. For that matter, I think
it'd be a significant improvement if there was NO way to enable
checksums, only disable them. That would at least allow us to enable
them by default in initdb and provide DBAs an easy way to disable them
if desired. That would get us a lot more data about whether checksums
help with corruption than we're going to get otherwise.
To put it another way, I think it's entirely reasonable *from a
technical standpoint* to enable by default in 10, with only the ability
to dynamically disable. Given the concerns that keep popping up about
dynamically enabling, I'm not at all sure that we could get that into 10.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)