Re: buffer assertion tripping under repeat pgbench load
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-12-24T16:31:19Z
Lists: pgsql-hackers
On 24 December 2012 16:25, Greg Smith <greg@2ndquadrant.com> wrote: > On 12/24/12 11:10 AM, Simon Riggs wrote: > >> I wonder if you're having a hardware problem? > > > Always possible. I didn't report this until I had replicated the crash and > seen exactly the same thing twice. I've seen it crash on this assertion 6 > times now. Bad hardware is not normally so consistent. Consistency in bugs is a wonderful thing, so I figure we can immediately rule out the hardware. > I kicked off another test that includes the block number just before Tom > suggested it, so I should have the block by tomorrow at the latest. The > range of runtime before crash is 3 to 14 hours so far. Tom will have fixed it by then ;-) Sorry, I should have mentioned it was the block number that I wanted and that was why I suggested using the other print function. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Follow TLI of last replayed record, not recovery target TLI, in walsenders.
- af275a12dfee 9.3.0 cited
-
Avoid holding vmbuffer pin after VACUUM.
- 62656617dbe4 9.3.0 cited