From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: buffer assertion tripping under repeat pgbench load |
Date: | 2012-12-24 16:10:23 |
Message-ID: | CA+U5nM+oJ-=es2EsUarW9pkziA-jsBGrdPx-jTmKsCpxEZ9QXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24 December 2012 15:57, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> 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?
PrivateRefCount is also one of the only large chunks of memory in a
running server where single bit errors aren't tolerated.
In shared buffers, most SLRUs or various other places, single bit
errors would often go unnoticed.
I wonder if you're having a hardware problem?,
If not, it might be worth looking to see if that block is the root,
maybe there's a problem in fastroot code, or something that only kicks
in with larger indexes.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-12-24 16:16:10 | Re: buffer assertion tripping under repeat pgbench load |
Previous Message | Tom Lane | 2012-12-24 16:07:00 | Re: buffer assertion tripping under repeat pgbench load |