Re: buffer assertion tripping under repeat pgbench load - Mailing list pgsql-hackers

From Tom Lane
Subject Re: buffer assertion tripping under repeat pgbench load
Date
Msg-id 5564.1356365220@sss.pgh.pa.us
Whole thread Raw
In response to Re: buffer assertion tripping under repeat pgbench load  (Greg Smith <greg@2ndQuadrant.com>)
Responses Re: buffer assertion tripping under repeat pgbench load  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Greg Smith <greg@2ndQuadrant.com> writes:
> I did get some output from the variation Andres suggested.  There was 
> exactly one screwed up buffer:

> 2012-12-24 06:08:46 EST [26015]: WARNING:  refcount of base/16384/49169 
> is 1073741824 should be 0, globally: 0

> That is pgbench_accounts_pkey.  1073741824 =
> 0100 0000 0000 0000 0000 0000 0000 0000 = 2^30

Huh.  Looks a bit like overflow of the refcount, which would explain why
it takes such a long test case to reproduce it.  But how could that be
happening without somebody forgetting to decrement the refcount, which
ought to lead to a visible failure in shorter tests?  Even more
interesting that the buffer's global refcount is zero.

Now that we know it's an index, it would be mighty useful to know which
block is the problem (I'm wondering if it's metapage or root).  Could
you add the block number to the printout?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Feature Request: pg_replication_master()
Next
From: Simon Riggs
Date:
Subject: Re: buffer assertion tripping under repeat pgbench load