On 21.01.2017 19:35, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
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
Yeah, and there's a bunch of usability tooling that we don't have,
centered around "what do you do after you get a checksum error?".
AFAIK there's no way to check or clear such an error; but without
such tools, I'm afraid that checksums are as much of a foot-gun
as a benefit.
I wanted to raise the same issue. A "something is broken" flag is fine
to avoid more things get broken. But if you can't repair them, its not
very useful.
Since i'm a heavy user of ZFS: there are checksums and if you enable
shadow-copies or using a raid, checksums are helpful, since the allow to
recover from the problems.
I personally would prefer to enable checksums manually and than get the
possibility to repair damages. Manually because this would at least
double the needed space.
Greetings,
Torsten
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
