Re: assertion failure 9.3.4

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: assertion failure 9.3.4
Дата
Msg-id 53515D2D.7080908@agliodbs.com
обсуждение исходный текст
Ответ на assertion failure 9.3.4  (Andrew Dunstan <andrew.dunstan@pgexperts.com>)
Список pgsql-hackers
On 04/18/2014 09:42 AM, Andrew Dunstan wrote:

> There definitely seems to be something going on involving these two
> pre-loaded modules. With both auto_explain and pg_stat_statements
> preloaded I can reproduce the error fairly reliably. I have also
> reproduced it, but less reliably, with auto_explain alone loaded. I have
> not reproduced it with pg_stat_statements alone loaded, but Josh Berkus
> has reported that another client has experienced something very similar
> (duplicate PK errors on a non-assertion-enabled build) with
> pg_stat_statements alone loaded.

Correct.   However, this seems to produce the issue less "reliably";
that is, it takes several hours of load testing for a duplicate PK to
show up, so I suspect that with pg_stat_statements alone it's also
timing issue.  I'm still waiting on the results with
pg_stat_statements.so NOT loaded to confirm that we're not actually
getting two separate bugs with similar symptoms.

The second site does not have any increase in query size.  Their only
settings for pg_s_s are:

pg_stat_statements.max = 10000
pg_stat_statements.track = all

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: How can we make beta testing better?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Clock sweep not caching enough B-Tree leaf pages?