From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Online verification of checksums |
Date: | 2020-11-10 04:44:11 |
Message-ID: | 20201110044411.GJ1887@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 05, 2020 at 10:57:16AM +0900, Michael Paquier wrote:
> I was referring to the patch I sent on this thread that fixes the
> detection of a corruption for the zero-only case and where pd_lsn
> and/or pg_upper are trashed by a corruption of the page header. Both
> cases allow a base backup to complete on HEAD, while sending pages
> that could be corrupted, which is wrong. Once you make the page
> verification rely only on pd_checksum, as the patch does because the
> checksum is the only source of truth in the page header, corrupted
> pages are correctly detected, causing pg_basebackup to complain as it
> should. However, it has also the risk to cause pg_basebackup to fail
> *and* to report as broken pages that are in the process of being
> written, depending on how slow a disk is able to finish a 8kB write.
> That's a different kind of wrongness, and users have two more reasons
> to be pissed. Note that if a page is found as torn we have a
> consistent page header, meaning that on HEAD the PageIsNew() and
> PageGetLSN() would pass, but the checksum verification would fail as
> the contents at the end of the page does not match the checksum.
Magnus, as the original committer of 4eb77d5, do you have an opinion
to share?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2020-11-10 04:54:20 | Re: Allow some recovery parameters to be changed with reload |
Previous Message | David Rowley | 2020-11-10 04:30:13 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |