Skip site navigation (1) Skip section navigation (2)

Re: GIN needs tonic

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: GIN needs tonic
Date: 2009-09-15 20:41:17
Message-ID: 1253047277.27962.22.camel@ebony.2ndQuadrant (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)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

> 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 

In response to


pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2009-09-15 20:42:26
Subject: Re: GIN needs tonic
Previous:From: Kevin GrittnerDate: 2009-09-15 20:20:51
Subject: Re: [BUGS] BUG #5053: domain constraints still leak

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group