On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote: > >> I've pointed out before that the regression tests are not particularly > >> meant to provide an exhaustive test of WAL recovery. In this particular > >> case, so far as I can tell the bug is only observable with > >> full_page_writes turned off --- otherwise XLogInsert will invariably > >> decide to log the full page, because it's going to see a zeroed-out > >> LSN in the passed-in buffer. > > > Yes, I was testing with full_page_writes = off at that point. > > In further testing, I've found that the CVS HEAD regression tests > actually will expose the error if you run them with full_page_writes off > and then force a WAL replay. (8.4 would not have, though, because of the > DROP TABLESPACE at the end of the run.) In any case, I stand by the > opinion that the standard regression tests aren't really meant to > exercise WAL recovery.
Yes, that's exactly how I located the first bug. Sorry if that wasn't clear. > BTW, there's more than one bug here :-(. Heikki found one, but the > code is also attaching the buffer indicator to the wrong rdata entry > --- the record header, not the workspace, is what gets suppressed > if the full page is logged. Well, whether they were meant to they do and to a much greater extent than any other body of tests that I'm aware of. Even if we had another test suite I would still expect recovery to handle a run on the primary of the full regression tests without problem. I look for multiple ways of testing and that is just one. I guess if you or another committer spends some time writing a test framework that is useful and that you can trust, I'm sure many people will add to it. That'll be true for any of the major/complex areas not covered by public test suites: concurrency, recovery and the optimizer. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
