Hello! I'm sorry that I could not answer at once.
Meanwhile I investigated the matter of my problem, learned about SSI (mostly at http://wiki.postgresql.org/wiki/Serializable) 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 <bu...@telenet.ru> wrote: KG> >> 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> 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.) KG> >> So what should I do? Do I need to increase >> "max_pred_locks_per_transaction" in postgresql.conf? KG> KG> Maybe, but let's rule out other problems first. KG> >> And how can I calculate desired value? KG> 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> KG> -Kevin With the best regards, Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
