Re: Postgres stucks in deadlock detection

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres stucks in deadlock detection
Date: 2018-04-04 14:56:54
Message-ID: bc4760c2-4d82-b73b-d7c9-138a47bd5a13@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> So, I see three possible ways to fix this problem:
> 1. Yury Sololov's patch with two phase deadlock check
I could be wrong, but LWLocks in pgsql aren't a "fair" locks: if LWLock is share
locked then exclusive lock will wait, but next shared lock will be acquired
immediately. If so, the we have a risk when two deadlocked processes will
infinitely wait for excluse lock over partitions while other processes will
repeady lock for share to find its owned deadlocks. I.e. lock graph has one loop
and members of that loop could not acquire exclusive lock becouse non-members of
loop constantly holds a share lock. It has a low probability, but nevertheless.

> 2. Avoid concurrent deadlock detection
Seems simple, workable solution with unpredicable delay for deadlock check.
Although it helps very good in cases when there isn't deadlock.

> 3. Avoid concurrent deadlock detection + let CheckDeadLock detect all deadlocks,
> not only those in which current transaction is involved.
I think, it's better solution, but I'm afraid it's too late for 11v...

--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marina Polyakova 2018-04-04 15:13:23 Add support for printing/reading MergeAction nodes
Previous Message Aleksandr Parfenov 2018-04-04 14:49:08 Re: new function for tsquery creartion