>From: Laurenz Albe <laurenz.albe@cybertec.at>
>Sent: Monday, February 17, 2020 10:53 AM
>To: Lars Aksel Opsahl <Lars.Opsahl@nibio.no>; pgsql-performance@lists.postgresql.org <pgsql-performance@lists.postgresql.org>
>Subject: Re: SubtransControlLock and performance problems
>
>Lars Aksel Opsahl wrote:
>> What happens is that after some minutes the CPU can fall to maybe 20% usage and most of
>> the threads are blocked by SubtransControlLock, and when the number SubtransControlLock
>> goes down the CPU load increases again. The jobs usually goes through without any errors,
>> but it takes to long time because of the SubtransControlLock blocks.
>
>That's typically a sign that you are using more than 64 subtransactions per transaction.
>
>That could either be SAVEPOINT SQL statements or PL/pgSQL code with blocks
>containing the EXCEPTION clause.
>
>The data structure in shared memory that holds information for each session
>can cache 64 subtransactions, beyond that it has to access "pg_subtrans" to get
> the required information, which leads to contention.
>
> Often the problem is caused by a misguided attempt to wrape every single
> statement in a subtransaction to emulate the behavior of other database
> systems, for example with the "autosave = always" option of the JDBC driver.
>
> The solution is to use fewer subtransactions per transaction.
>
Hi
I have tested in branch ( https://github.com/larsop/resolve-overlap-and-gap/tree/add_postgis_topology_using_func) where I use only have functions and no procedures and I still have the same problem with subtransaction locks.
Can I based on this assume that the problem is only related to exceptions ?
Does this mean that if have 32 threads running in parallel and I get 2 exceptions in each thread I have reached a state where I will get contention ?
Is it any way increase from 64 to a much higher level, when compiling the code ?
Basically what I do here is that I catch exceptions when get them and tries to solve the problem in a alternative way.
Thanks a lot.
Lars
