Re: How to produce a Soft Block case of Deadlock Detection? - Mailing list pgsql-hackers

From Rui Hai Jiang
Subject Re: How to produce a Soft Block case of Deadlock Detection?
Date
Msg-id CAEri+mLq3nrTHxYUoYjTW9ki7QPSxRjzbJzZLRqdyHPq+3WH_w@mail.gmail.com
Whole thread Raw
In response to How to produce a Soft Block case of Deadlock Detection?  (Rui Hai Jiang <ruihaij@gmail.com>)
List pgsql-hackers
I finally found this.


This is very useful to understand the Soft Block.

On Wed, Jun 19, 2019 at 7:18 PM Rui Hai Jiang <ruihaij@gmail.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;
            

pgsql-hackers by date:

Previous
From: Oleksii Kliukin
Date:
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Next
From: Tom Lane
Date:
Subject: Re: psql UPDATE field [tab] expands to DEFAULT?