Re: Offline enabling/disabling of data checksums
От | Michael Paquier |
---|---|
Тема | Re: Offline enabling/disabling of data checksums |
Дата | |
Msg-id | 20181228013027.GD3210@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Offline enabling/disabling of data checksums (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: