From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Michael Banck <michael(dot)banck(at)credativ(dot)de>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: Online verification of checksums |
Date: | 2018-09-26 15:18:21 |
Message-ID: | alpine.DEB.2.21.1809261714060.22248@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Stephen,
> I certainly don't see a lot of point in doing much more than what was
> discussed previously for 'new' blocks (counting them as skipped and
> moving on).
Sure.
> An actual read() error (that is, a failure on a read() call such as
> getting back EIO), on the other hand, is something which I'd probably
> report back to the user immediately and then move on, and perhaps
> report again at the end.
Yep.
> Note that a short read isn't an error and falls under the 'new' blocks
> discussion above.
I'm really unsure that a short read should really be coldly skipped:
If the check is offline, then one file is in a very bad state, this is
really a panic situation.
If the check is online, given that both postgres and the verify command
interact with the same OS (?) and at the pg page level, I'm not sure in
which situation there could be a partial block, because pg would only
send full pages to the OS.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-09-26 15:30:31 | Re: Online verification of checksums |
Previous Message | Michael Banck | 2018-09-26 15:15:27 | Re: Online verification of checksums |