Hello On 2018-Aug-01, Andres Freund wrote:
> My problem isn't just that I shouldn't think this should be committed > without at least a firm committement to do better, I take "I think this shouldn't be committed" is what you meant. I'm not sure I agree with this line of argument. The reality is that real life or diverging priorities preclude people from working on $stuff. This is a useful feature-1 we have here, and if we stall it until we have feature-2, we may not get either until a year later. That's not a great outcome. We didn't wait for partitioning, parallel query, DDL progress reporting, logical replication, JIT, wait events (to name but a few) to solve world's hunger in order to start getting committed. We move forward step by step, and that's a good thing. Firm commitments are great things to have, and if the firmness leads to feature-2 being part of the same release, great, but if it's not firm enough, we can have feature-2 the next release (or whenever). Even if there's no such commitment, feature-1 is useful on its own. > my problem is that I think the "restart" approach is just using the > entirely wrong hammer to solve the problem at hand. At the very least > it's very problematic in respect to replicas, which need to know about > the setting too, and can have similar problems the restart on the > primary is supposed to prevent. If we define "restart" to mean taking all the servers down simultaneously, that can be planned. For users that cannot do that, that's too bad, they'll have to wait to the next release in order to enable checksums (assuming they fund the necessary development). But there are many systems where it *is* possible to take everything down for five seconds, then back up. They can definitely take advantage of checksummed data. Currently, the only way to enable checksums is to initdb and create a new copy of the data from a logical backup, which could take hours or even days if data is large, or use logical replication. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services