| From: | Evgeniy Shishkin <itparanoia(at)gmail(dot)com> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Postgres stucks in deadlock detection |
| Date: | 2018-04-13 15:22:45 |
| Message-ID: | 2ED40611-BBC2-43CF-B5A9-B48EA03030E1@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Apr 5, 2018, at 11:03, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>
> From the other side, the fact that any of this
>
> a) increasing deadlock timeout
> b) avoid concurrent execution of deadlock check
> c) perform first stage of deadlock check under shared lock
>
> have very noticeable effect on the observed behavior and some of them allow to completely eliminate the problem,
> makes me think that deadlock detection is not a symptom but the main source of the problem.
It seems to me that instead of running deadlock detection one-by-one you can use exponential backoff.
It should provide "good" degradation during high contention and does not make things bad on low contention.
Maybe you should combine it with Yura's patch for additional benefit and benchmark it on different contentions.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-04-13 15:41:39 | Re: Postgres stucks in deadlock detection |
| Previous Message | Alvaro Herrera | 2018-04-13 14:50:44 | Re: [HACKERS] path toward faster partition pruning |