Re: Postgres stucks in deadlock detection

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres stucks in deadlock detection
Date: 2018-04-20 16:51:41
Message-ID: 20180420165141.5gduqk3m46afyaem@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Konstantin Knizhnik wrote:

> As I have mentioned at the beginning of this thread the same problem with
> deadlock detection timeout expiration we have with YSCB benchmark with zipf
> distribution.
> Here the source of contention are tuple locks. And as far as I understand
> from the discussion in the mentioned thread, it is not possible to eliminate
> heavy weight tuple locks.

Well, if the source of tuple locks are foreign keys, maybe we can fix
that problem by removing the need for tuple locks in the first place --
for example, mark a table as prohibiting DELETEs, TRUNCATE, and any
UPDATE that modifies the columns of the primary key. With that, you
don't need to lock rows in the FK triggers. (This is like 'ALTER TABLE
tb SET READ ONLY', except the restrictions are less severe).

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-20 17:39:17 Re: Foreign keys and partitioned tables
Previous Message Konstantin Knizhnik 2018-04-20 16:45:06 Re: [HACKERS] Custom compression methods