| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Online verification of checksums |
| Date: | 2019-03-18 06:05:59 |
| Message-ID: | 20190318060559.GF1885@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Mar 18, 2019 at 01:43:08AM -0400, Stephen Frost wrote:
> To be clear, I agree completely that we don't want to be reporting false
> positives or "this might mean corruption!" to users running the tool,
> but I haven't seen a good explaination of why this needs to involve the
> server to avoid that happening. If someone would like to point that out
> to me, I'd be happy to go read about it and try to understand.
The mentions on this thread that the server has all the facility in
place to properly lock a buffer and make sure that a partial read
*never* happens and that we *never* have any kind of false positives,
directly preventing the set of issues we are trying to implement
workarounds for in a frontend tool are rather good arguments in my
opinion (you can grep for BufferDescriptorGetIOLock() on this thread
for example).
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2019-03-18 06:07:27 | Re: Offline enabling/disabling of data checksums |
| Previous Message | Stephen Frost | 2019-03-18 05:52:14 | Re: Compressed TOAST Slicing |