Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault
Date
Msg-id 4F0D55D80200002500044695@gw.wicourts.gov
Whole thread Raw
In response to Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault  (Andrew Alcheyev <buddy@telenet.ru>)
Responses Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: FreeBSD 9.0/amd64, PostgreSQL 9.1.2, pgbouncer 1.4.2: segmentation fault  (Andrew Alcheyev <buddy@telenet.ru>)
List pgsql-bugs
Andrew Alcheyev <buddy@telenet.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.

> And how can I calculate desired value?

You would need to review pg_locks under load to get a handle on
that.  I don't think anyone has devised any generalized formula yet,
but if we rule out other problems, I'd be happy to review your lock
situation and make suggestions.

-Kevin

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #6393: cluster sometime fail under heavy concurrent write load
Next
From: "Kevin Grittner"
Date:
Subject: Re: Postgres Backup and Restore