Re: assertion failure 9.3.4

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: assertion failure 9.3.4
Date: 2014-04-18 17:13:17
Message-ID: 53515D2D.7080908@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-04-18 19:37:36 Re: Clock sweep not caching enough B-Tree leaf pages?
Previous Message Josh Berkus 2014-04-18 16:53:27 Re: How can we make beta testing better?