Re: buffer assertion tripping under repeat pgbench load
Peter Geoghegan <peter@2ndquadrant.com>
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>, Greg Stark <stark@mit.edu>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, Andres Freund <andres@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-12-30T04:45:02Z
Lists: pgsql-hackers
On 30 December 2012 04:37, Robert Haas <robertmhaas@gmail.com> wrote: > On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith <greg@2ndquadrant.com> wrote: >> It is a strange power of two to be appearing there. I can follow your >> reasoning for why this could be a bit flipping error. There's no sign of >> that elsewhere though, no other crashes under load. I'm using this server >> here because it's worked fine for a while now. > > In theory, if this is sufficiently reproducible, could you start > backing up through the commit history 100 or so commits at a time > until you find the culprit? Or use git bisect? It'd be kind of > time-consuming, but... FYI, Andrew Dunstan recently blogged about using git bisect to find problems in Postgres. His example shell script will save you the trouble of independently coming up with much the same boilerplate (the non-boilerplate parts are probably what you need to worry about, though). http://people.planetpostgresql.org/andrew/index.php?/archives/301-Finding-the-origin-of-problems-with-git-bisect.html If you try and do a binary search through many commits *manually*, for a bug that is this hard to reproduce, well, that's no fun. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and 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