| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, 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:07:00 |
| Message-ID: | 5564.1356365220@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Smith <greg(at)2ndQuadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-12-24 16:10:23 | Re: buffer assertion tripping under repeat pgbench load |
| Previous Message | Simon Riggs | 2012-12-24 15:57:10 | Re: Feature Request: pg_replication_master() |