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

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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andrew Alcheyev" <buddy(at)telenet(dot)ru>
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-17 18:56:01
Message-ID: 4F156FE102000025000448A3@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> 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.
>  
> I noticed that you are using prepared transactions.  Do you have
> any lingering transactions prepared but not committed or rolled
> back?  (You can look in pg_prepared_xacts, and see when they were
> prepared.)
>  
>> So what should I do? Do I need to increase
>> "max_pred_locks_per_transaction" in postgresql.conf?
>  
> Maybe, but let's rule out other problems first.
 
Has this been resolved?  Any details would be useful to us.
 
-Kevin

In response to

pgsql-bugs by date

Next:From: David SchnurDate: 2012-01-17 21:46:50
Subject: Re: Repeatable crash in pg_dump (with -d2 info)
Previous:From: Noah MischDate: 2012-01-17 18:23:36
Subject: Re: fatal flex error in guc-file.l kills the postmaster

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