Duncan Rance <postgres(at)dunquino(dot)com> writes:
> On 3 Feb 2012, at 06:45, Tom Lane wrote:
>> I probably ought to let the test case run overnight before concluding
>> anything, but at this point it's run for two-plus hours with no errors
>> after applying this patch:
> Thank Tom! I've had this running for a few hours now without problems. Previously, on Sparc, the problem would occur in less than a minute.
> I did try a build with --enable-cassert and it didn't actually cause the problem. I think I left it for about an hour. Although a a relatively modern machine, this Sparc box I am using is painfully slow. My guess is that the extra time taken to perform the Assert code is hiding the problem.
My machine has been running the test case for twelve hours now with no
errors, whereas with the bug the MTTF seemed to be half an hour or so.
(Hm, I wonder whether turning off asserts would reduce the time to
failure? Probably not worth the trouble to experiment now.) So I think
we've got it, or at least we've found the problems this test case can
expose. I'm still going to go read all the other WAL replay code...
> Now it's time to persuade the customer to use a patched version of pg ;)
FWIW, this bug might persuade us to do a set of releases pretty soon.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2012-02-03 16:12:33|
|Subject: Re: Review of: explain / allow collecting row counts
without timing info|
|Previous:||From: Joachim Wieland||Date: 2012-02-03 15:43:17|
|Subject: Re: patch for parallel pg_dump|
pgsql-bugs by date
|Next:||From: Mark Phillips||Date: 2012-02-03 17:07:08|
|Subject: Re: BUG #6404: postgres account not created during unattended install|
|Previous:||From: Duncan Rance||Date: 2012-02-03 15:24:50|
|Subject: Re: BUG #6425: Bus error in slot_deform_tuple |