| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Banck <michael(dot)banck(at)credativ(dot)de> |
| Cc: | Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Online verification of checksums |
| Date: | 2020-04-06 20:45:44 |
| Message-ID: | 19763.1586205944@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Grigory Smolkin | 2020-04-06 20:46:01 | Re: archive recovery fetching wrong segments |
| Previous Message | Tomas Vondra | 2020-04-06 20:42:22 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |