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 <buddy@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.
