Re: How to produce a Soft Block case of Deadlock Detection?

From: Rui Hai Jiang <ruihaij(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to produce a Soft Block case of Deadlock Detection?
Date: 2019-06-19 14:27:03
Message-ID: CAEri+mLq3nrTHxYUoYjTW9ki7QPSxRjzbJzZLRqdyHPq+3WH_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I finally found this.

https://www.postgresql.org/message-id/29104.1182785028%40sss.pgh.pa.us

This is very useful to understand the Soft Block.

On Wed, Jun 19, 2019 at 7:18 PM Rui Hai Jiang <ruihaij(at)gmail(dot)com> wrote:

> Hello, hackers.
>
> Any body know how to produce a Soft Block case of Deadlock Detection?
> I have produced the Hard Block case, but can't produce the Soft Block case.
>
>
> I read the design: src/backend/storage/lmgr/README. It reads,
>
> "If a process A is behind a process B in some lock's wait queue, and
> their requested locks conflict, then we must say that A waits for B, since
> ProcLockWakeup will never awaken A before B. This creates additional
> edges in the WFG. We call these "soft" edges, as opposed to the "hard"
> edges induced by locks already held. Note that if B already holds any
> locks conflicting with A's request, then their relationship is a hard edge
> not a soft edge."
>
>
> But after trying many testing, I couldn't figure out how to produce a Soft
> Block.
>
> Following is what I did.
>
> * Hard Block Case
>
> ** Prepare
>
> create table t1 ( id int primary key, test int );
> create table t2 ( id int primary key, test int );
>
> insert into t1 values (10,10);
> insert into t2 values (20,20);
>
> ** test
>
> step1/backend1:
> begin;
> update t1 set test=11 where id=10;
>
> step2/backend2:
> begin;
> update t2 set test=21 where id=20;
>
> step3/backend1:
> update t2 set test=21 where id=20;
>
> step4/process2: /*deadlock detected*/
> update t1 set test=11 where id=10;
>
>
>
>
> * Soft Block Case
>
> ** Prepare
>
> create table t1 ( id int primary key, test int );
>
> create table t2 ( id int primary key, test int );
>
> create table t3 ( id int primary key, test int );
>
> insert into t1 values (10,10);
> insert into t2 values (20,20);
> insert into t3 values (30,30);
>
> ** test
>
> step1/backend1: /*lock t1.row1*/
> begin;
> select * from t1 where id=10 for update;
>
>
> step2/backend2: /*lock t2.row1*/
> begin;
> select * from t2 where id=20 for no key update;
>
> step3/backend3: /*lock t2.row1*/
> begin;
> select * from t2 where id=20 for key share;
>
> step4/backend4:/*lock t3.row1*/
> begin;
> select * from t3 where id=30 for update;
>
> step5/backend4:/*try to lock t1.row1*/
> update t1 set id=11 where id=10;
>
> step6/backend3:/*try to lock t3.row1*/
> update t3 set id=31 where id=30;
>
> step7/backend5:/*try to lock t2.row1, hope to create a soft edge*/
> begin;
> update t2 set id=21 where id=20;
>
> step8/backend1:/*try to lock t2.row1*/ /*Expect to detect soft block,
> but there seems no soft block*/
> update t2 set test=21 where id=20;
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-06-19 14:39:24 Re: psql UPDATE field [tab] expands to DEFAULT?
Previous Message Oleksii Kliukin 2019-06-19 14:08:31 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock