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  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: buffer assertion tripping under repeat pgbench load  (Simon Riggs <simon@2ndQuadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Feature Request: pg_replication_master()
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Feature Request: pg_replication_master()