On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
> Simon Riggs <simon@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
