From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres stucks in deadlock detection |
Date: | 2018-04-04 18:15:43 |
Message-ID: | 20180404181542.2p2r62jfftqdrem3@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2018-04-04 18:22:48 | Re: pgsql: Validate page level checksums in base backups |
Previous Message | Simon Riggs | 2018-04-04 18:08:20 | Re: Add support for printing/reading MergeAction nodes |