On Fri, Dec 28, 2018 at 01:14:05AM +0100, Tomas Vondra wrote:
> I'm sorry, but I'm not sure I understand the question. Of course, asking
> over at -packagers won't hurt, but my guess is the response will be it's
> not a big deal from the packaging perspective.
(The previous email had an extra "Would"... Sorry.)
Let's ask those folks then.
> What do you mean by "control" here? Dealing with checksum failures, or
> some additional capabilities?
What I am referring to here is the possibility to enable, disable and
check checksums for an online cluster. I am not sure what kind of
tooling able to do chirurgy at page level would make sense. Once a
checksum is corrupted a user knows about a problem, which mainly needs
a human lookup.
> I'm not sure data checksums are particularly great evidence. For example
> with the recent fsync issues, we might have ended with partial writes
> (and thus invalid checksums). The OS migh have even told us about the
> failure, but we've gracefully ignored it. So I'm afraid data checksums
> are not a particularly great proof it's not our fault.
Sure, they are not a solution to all problems. Still they give hints
before the problem spreads, and sometimes by looking at one corrupted
page by yourself one can see if the data fetched from disk comes from
Postgres or not (say inspecting the page header with pageinspect,
etc.).
--
Michael
