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: http://www.postgresql.org/mailpref/pgsql-hackers
