On 1/23/17 12:03 PM, Greg Stark wrote:
On Jan 22, 2017 11:13 AM, "Magnus Hagander" <mag...@hagander.net
<mailto:mag...@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)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to