* Andres Freund (andres@anarazel.de) wrote:
> On 2017-01-21 13:03:52 -0500, Stephen Frost wrote:
> > * Andres Freund (andres@anarazel.de) wrote:
> > > On 2017-01-21 12:46:05 -0500, Stephen Frost wrote:
> > > > Do you run with all defaults in those environments?
> > >
> > > Irrelevant - changing requires re-initdb'ing. That's unrealistic.
> >
> > I disagree. Further, we can add an option to be able to disable
> > checksums without needing to re-initdb pretty trivially, which addresses
> > the case where someone's having a problem because it's enabled, as
> > discussed.
>
> Sure, it might be easy, but we don't have it. Personally I think
> checksums just aren't even ready for prime time. If we had:
> - ability to switch on/off at runtime (early patches for that have IIRC
> been posted)
> - *builtin* tooling to check checksums for everything
> - *builtin* tooling to compute checksums after changing setting
> - configurable background sweeps for checksums
I'm certainly all for adding, well, all of that.
I don't think we need *all* of it before considering enabling checksums
by default, but I do think it'd be great if we had people working on
adding those.
> then the story would look differently. Right now checksums just aren't
> particularly useful due to not having the above. Just checking recent
> data doesn't really guarantee much - failures are more likely in old
> data, and the data might even be read from ram.
I agree that failures tend to be more likely in old data, though, as
with everything, "it depends."
Thanks!
Stephen