Re: [patch] Fix checksum verification in base backups for zero page headers

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [patch] Fix checksum verification in base backups for zero page headers
Date: 2020-10-22 12:11:45
Message-ID: 036235b4-2461-c4b2-a448-7875d943ce1e@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.10.2020 04:25, Michael Paquier wrote:
> On Thu, Oct 22, 2020 at 12:47:03AM +0300, Anastasia Lubennikova wrote:
>> We can also read such pages via shared buffers to be 100% sure.
> Yeah, but this has its limits as well. One can use
> ignore_checksum_failure, but this can actually be very dangerous as
> you can finish by loading into shared buffers a page that has a header
> thought as sane but with a large portion of its page randomly
> corrupted, spreading corruption around and leading to more fancy
> logic failures in Postgres, with more panic from customers. Not using
> ignore_checksum_failure is safer, but it makes an analyze of the
> damages for a given file harder as things would stop at the first
> failure of a file with a seqscan. pg_prewarm can help here, but
> that's not the goal of the tool to do that either.
I was thinking about applying this only to pages with LSN > startLSN.

Most of such pages are valid and already in memory, because they were
changed just recently, so no need for pg_prewarm here. If such LSN
appeared because of a data corruption, page verification from inside
ReadBuffer() will report an error first. In proposed function, we can
handle this error in any fashion we want. Something like:

if (PageGetLSN(page) > startptr)
{
    if (!read_page_via_buffercache())

        //throw a warning about corrupted page
        //handle checksum error as needed
    else
        //page is valid. No worries
}

--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-10-22 12:26:55 Re: [HACKERS] Custom compression methods
Previous Message Thomas Munro 2020-10-22 12:00:07 Re: Collation versioning