Can an INSERT operation result in a deadlock?

Question

Assuming:

• I am using REPEATABLE_READ or SERIALIZABLE transaction isolation (locks get retained every time I access a row)
• We are talking about multiple th

Answer 1

In addition to LoztInSpace's answer, inserts may cause deadlocks even without deletes or updates presence. All you need is a unique index and a reversed operations order.

Example in Oracle :

create table t1 (id number);
create unique index t1_pk on t1 (id);

--thread 1 :
insert into t1 values(1);
--thread 2
insert into t1 values(2);
--thread 1 :
insert into t1 values(2);
--thread 2
insert into t1 values(1);  -- deadlock !

Answer 2

Let us assume you have two relations A and B and two users X and Y. Table A is WRITE Locked by user X and Table B is WRITE Locked by Y. Then the following query will give you a dead lock if used by both the users X and Y.

Select * from A,B

So clearly a Select operation can cause a deadlock if join operations involving more than one table is a part of it. Usually Insert and Delete operations involve single relations. So they may not cause deadlock.

Answer 3

Generally all modifications can cause a deadlock and selects will not (get to that later). So

1. No you cannot ignore these.
2. You can somewhat ignore select depending on your database and settings but the others will give you deadlocks.

You don't even need multiple tables.

The best way to create a deadlock is to do the same thing in a different order.

SQL Server examples:

create table A
(
    PK int primary key
)

Session 1:

begin transaction
insert into A values(1)

Session 2:

begin transaction    
insert into A values(7)

Session 1:

delete from A where PK=7

Session 2:

delete from A where PK=1

You will get a deadlock. So that proved inserts & deletes can deadlock.

Updates are similar:

Session 1:

begin transaction    
insert into A values(1)
insert into A values(2)
commit

begin transaction
update A set PK=7 where PK=1

Session 2:

begin transaction
update A set pk=9 where pk=2    
update A set pk=8 where pk=1

Session 1:

update A set pk=9 where pk=2

Deadlock!

SELECT should never deadlock but on some databases it will because the locks it uses interfere with consistent reads. That's just crappy database engine design though.

SQL Server will not lock on a SELECT if you use SNAPSHOT ISOLATION. Oracle & I think Postgres will never lock on SELECT (unless you have FOR UPDATE which is clearly reserving for an update anyway).

So basically I think you have a few incorrect assumptions. I think I've proved:

1. Updates can cause deadlocks
2. Deletes can cause deadlocks
3. Inserts can cause deadlocks
4. You do not need more than one table
5. You do need more than one session

You'll just have to take my word on SELECT ;) but it will depend on your DB and settings.