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

  1. Follow TLI of last replayed record, not recovery target TLI, in walsenders.

  2. Avoid holding vmbuffer pin after VACUUM.