Hi, On 2018-04-04 11:54:14 +0300, Konstantin Knizhnik wrote: > Several times we and our customers are suffered from the problem that > Postgres got stuck in deadlock detection. > One scenario is YCSB workload with Zipf's distribution when many clients are > trying to update the same record and compete for it's lock.
> Another scenario is large number of clients performing inserts in the same > table. In this case the source of the problem is relation extension lock. > In both cases number of connection is large enough: several hundreds. Have you ever observed that in the field? This sounds more artificial than real to me. > So, I see three possible ways to fix this problem: > 1. Yury Sololov's patch with two phase deadlock check > 2. Avoid concurrent deadlock detection > 3. Avoid concurrent deadlock detection + let CheckDeadLock detect all > deadlocks, not only those in which current transaction is involved. 4) Don't do anything about deadlock detection, because this is just a symptom five steps removed from the cause. We've to pay attention to fixing actual problems, rather than purely benchmark ones. Complexity has a significant price. Greetings, Andres Freund
