Re: buffer assertion tripping under repeat pgbench load
От | Greg Smith |
---|---|
Тема | Re: buffer assertion tripping under repeat pgbench load |
Дата | |
Msg-id | 50D87B4F.6050603@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: buffer assertion tripping under repeat pgbench load (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: buffer assertion tripping under repeat pgbench load
Re: buffer assertion tripping under repeat pgbench load |
Список | 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 по дате отправления: