Re: Online verification of checksums - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Online verification of checksums
Date
Msg-id 19763.1586205944@sss.pgh.pa.us
Whole thread Raw
In response to Re: Online verification of checksums  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Online verification of checksums  (Michael Banck <michael.banck@credativ.de>)
List pgsql-hackers
I wrote:
> Another thing that's bothering me is that the patch compares page LSN
> against GetInsertRecPtr(); but that function says
> ...
> I'm not convinced that an approximation is good enough here.  It seems
> like a page that's just now been updated could have an LSN beyond the
> current XLOG page start, potentially leading to a false checksum
> complaint.  Maybe we could address that by adding one xlog page to
> the GetInsertRecPtr result?  Kind of a hack, but ...

Actually, after thinking about that a bit more: why is there an LSN-based
special condition at all?  It seems like it'd be far more useful to
checksum everything, and on failure try to re-read and re-verify the page
once or twice, so as to handle the corner case where we examine a page
that's in process of being overwritten.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Next
From: Grigory Smolkin
Date:
Subject: Re: archive recovery fetching wrong segments