Re: Postgres stucks in deadlock detection
От | Andres Freund |
---|---|
Тема | Re: Postgres stucks in deadlock detection |
Дата | |
Msg-id | 20180404181542.2p2r62jfftqdrem3@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Postgres stucks in deadlock detection (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: Postgres stucks in deadlock detection
Re: Postgres stucks in deadlock detection |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: