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
-
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