Greetings, * Michael Banck (michael.ba...@credativ.de) wrote: > On Tue, Oct 30, 2018 at 06:22:52PM +0100, Fabien COELHO wrote: > > The "check if page was modified since checkpoint" does not look useful when > > offline. Maybe it lacks a comment to say that this cannot (should not ?) > > happen when offline, but even then I would not like it to be true: ISTM that > > no page should be allowed to be skipped on the checkpoint condition when > > offline, but it is probably ok to skip with the new page test, which make me > > still think that they should be counted and reported separately, or at least > > the checkpoint skip test should not be run when offline. > > What is the rationale to not skip on the checkpoint condition when the > instance is offline? If it was shutdown cleanly, this should not > happen, if the instance crashed, those would be spurious errors that > would get repaired on recovery. > > I have not changed that for now.
Agreed- this is an important check even in offline mode. > > When offline, the retry logic does not make much sense, it should complain > > directly on the first error? Also, I'm unsure of the read & checksum retry > > logic *without any delay*. The race condition being considered here is where an 8k read somehow gets the first 4k, then is scheduled off-cpu, and the full 8k page is then written by some other process, and then this process is woken up to read the second 4k. I agree that this is unnecessary when the database is offline, but it's also pretty cheap. When the database is online, it's an extremely unlikely case to hit (just try to reproduce it...) but if it does get hit then it's easy enough to recheck by doing a reread, which should show that the LSN has been updated in the first 4k and we can then know that this page is in the WAL. We have not yet seen a case where such a re-read returns an old LSN and an invalid checksum; based on discussion with other hackers, that shouldn't be possible as every kernel seems to consistently write in-order, meaning that the first 4k will be updated before the second, so a single re-read should be sufficient. Remember- this is all in-memory activity also, we aren't talking about what might happen on disk here. > I think the small overhead of retrying in offline mode even if useless > is worth avoiding making the code more complicated in order to cater for > both modes. Agreed. > Initially there was a delay, but this was removed after analysis and > requests by several other reviewers. Agreed, there's no need for or point to having such a delay. > > >>This might suggest some option to tell the command that it should work in > > >>online or offline mode, so that it may be stricter in some cases. The > > >>default may be one of the option, eg the stricter offline mode, or maybe > > >>guessed at startup. > > > > > >If we believe the operation should be different, the patch removes the > > >"is cluster online?" check (as it is no longer necessary), so we could > > >just replace the current error message with a global variable with the > > >result of that check and use it where needed (if any). > > > > That could let open the issue of someone starting the check offline, and > > then starting the database while it is not finished. Maybe it is not worth > > sweating about such a narrow use case. > > I don't think we need to cater for that, yeah. Agreed. > > It would also be nice if the test could apply on an active database, > > eg with a low-rate pgbench running in parallel to the verification, > > but I'm not sure how easy it is to add such a thing. > > That sounds much more complicated so I have not tackled that yet. I agree that this would be nice, but I don't want the regression tests to become much longer... Thanks! Stephen
signature.asc
Description: PGP signature
