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