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

From Greg Smith
Subject Re: buffer assertion tripping under repeat pgbench load
Date
Msg-id 50D87B4F.6050603@2ndQuadrant.com
Whole thread Raw
In response to Re: buffer assertion tripping under repeat pgbench load  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: buffer assertion tripping under repeat pgbench load  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: buffer assertion tripping under repeat pgbench load  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 12/23/12 3:17 PM, Simon Riggs wrote:
> We already have PrintBufferLeakWarning() for this, which might be a bit neater.

Maybe. I tried using this, and I just got a seg fault within that code.  I can't figure out if I called it incorrectly
orif the buffer 
 
involved is so damaged that PrintBufferLeakWarning chokes on it.  I'll 
look at that myself later.

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

Pretty odd value to find in a PrivateRefCount.  What makes me nervous 
about all of the PrivateRefCount coding is how it switches between 
references like PrivateRefCount[(bufnum) - 1] and PrivateRefCount[b]. 
Might this be an off by one error in one of those, where the wrong form 
was used?

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Feature Request: pg_replication_master()
Next
From: Simon Riggs
Date:
Subject: Re: Feature Request: pg_replication_master()