Re: buffer assertion tripping under repeat pgbench load

Greg Smith <greg@2ndquadrant.com>

From: Greg Smith <greg@2ndQuadrant.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-12-24T15:57:03Z
Lists: 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 or if 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


Commits

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

  2. Avoid holding vmbuffer pin after VACUUM.