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;
>
>
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 |