Skip site navigation (1) Skip section navigation (2)

Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault

From: Andrew Alcheyev <buddy(at)telenet(dot)ru>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault
Date: 2012-01-24 12:59:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs

I'm sorry that I could not answer at once.

Meanwhile I investigated the matter of my problem, learned about SSI
(mostly at and
realized that we wouldn't need "serializable" transaction isolation
level anymore (thanks to SSI). So I just turned it off within the
settings of the problematic client and thus resolved the issue we had
at our production server. 

I don't think I'd like to reproduce the situation intentionally
whenever because it breaks the normal flow of our important operations
and provokes manual intervention to data processing.

On Wednesday, January 11, 2012, 9:26:48 PM you wrote:

KG> Andrew Alcheyev <buddy(at)telenet(dot)ru> wrote:
>> Well, it does good and the backend hasn't crashed yet, but the
>> client is still experiencing query problems at some point (not
>> far, I guess, from where its backend would segfault without the
>> patch). This time it encounters the following error from the
>> backend:
>> ERROR:  out of shared memory
>> HINT:  You might need to increase max_pred_locks_per_transaction.
KG> I noticed that you are using prepared transactions.  Do you have any
KG> lingering transactions prepared but not committed or rolled back? 
KG> (You can look in pg_prepared_xacts, and see when they were
KG> prepared.)
>> So what should I do? Do I need to increase
>> "max_pred_locks_per_transaction" in postgresql.conf?
KG> Maybe, but let's rule out other problems first.
>> And how can I calculate desired value?
KG> You would need to review pg_locks under load to get a handle on
KG> that.  I don't think anyone has devised any generalized formula yet,
KG> but if we rule out other problems, I'd be happy to review your lock
KG> situation and make suggestions.
KG> -Kevin

With the best regards, Andrew.

In response to

pgsql-bugs by date

Next:From: Giuseppe SucameliDate: 2012-01-24 13:41:56
Subject: Re: Different error messages executing CREATE TABLE or ALTER TABLE to create a column "xmin"
Previous:From: Tom LaneDate: 2012-01-24 05:43:08
Subject: Re: Segfault in backend CTE code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group