任何数据库都有死锁，MYSQL的死锁有相关的工具，或者去日志查找，postgresql的死锁又怎么搞，今天的来说说。
首先来说postgresql 检测死锁在配置文件中是有相关配置的，在postgresql中有三个和查询有关的超时设置
deadlock_timeout 进行死锁检测之前在一个锁上等待的总时间
lock_timeout 锁等待超时。语句在试图获取表、索引、行或其他数据库对象上的锁时等到超过指定的毫秒数，该语句将被中止。不推荐在postgresql.conf中设置。
statement_timeout 控制语句执行时长，单位是ms。超过设定值，该语句将被中止。
这三个里面的设置，死锁的检测一定是要设置的，因为死锁被发现时，最好是尽快的通过系统检测到后，尽快的解除（牺牲一个）。保证系统正常的运行，尤其在OLTP的系统中。所以这里一般可以设置一个较短的值，例如1秒。
lock_timeout 这个属于 A 有 B 的资源，B需要等待A 的资源释放后等待可以忍受的时间，一般来说，如果不是故意例如 写完begin 后不操作 commit,任务很快的完成的情况下，一般来说我们不设置 lock_timeout ，当然如果在一个糟糕的系统中，经常发生霸占资源不释放的状态，这样的不设置也可以很快发现问题。（稍后会给出语句）。
statement_timeout 类似于MYSQL 也有类似的设置或者通过PT工具来进行设置，将超过运行设定时间的语句，KILL掉，这里面我们也是一般不进行设置的。
不进行设置默认是一直等待。
OK 我们先来看一下什么是死锁，这里我们稍微的把死锁的鉴定的时间调大一点，好来给执行发现死锁的语句一点时间，我们将deadlock_timeout 设置为 20秒，当然如果是生产系统，你这样做，呵呵 你还想干吗？
我们启动两个session 其中一个
Session 1
1 test=# begin;
BEGIN
2 test=# update test set value = 'tyyu' where id =3;
UPDATE 1
5 test=# update test set value = 'tyyu' where id =2;
Session 2
3 test=# begin;
BEGIN
4 test=# update test set value = 'tyyu' where id =2;
UPDATE 1
6 test=# update test set value = 'tyyu' where id =3;
大家可以看我的执行语句前面的序号
在系统里面等待20秒后
系统会给出死锁的信息以及相关解决的信息，当然如果在死锁期间，通过语句你也是可以发现相关的死锁信息的。
SELECT blocked_locks.pid AS blocked_pid,
blocked_activity.usename AS blocked_user,
blocking_locks.pid AS blocking_pid,
blocking_activity.usename AS blocking_user,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
反过来我们去查看日志
CST [15798] LOG: duration: 74.150 ms
CST [15788] LOG: process 15788 detected deadlock while waiting for ShareLock on transaction 678 after 20003.487 ms
CST [15788] DETAIL: Process holding the lock: 15786. Wait queue: .
CST [15788] CONTEXT: while updating tuple (0,3) in relation "test"
[15788] STATEMENT: update test set value = 'tyyu' where id =3;
CST [15788] ERROR: deadlock detected
CST [15788] DETAIL: Process 15788 waits for ShareLock on transaction 678; blocked by process 15786.
Process 15786 waits for ShareLock on transaction 679; blocked by process 15788.
Process 15788: update test set value = 'tyyu' where id =3;
Process 15786: update test set value = 'tyyu' where id =2;
CST [15788] HINT: See server log for query details.
CST [15788] CONTEXT: while updating tuple (0,3) in relation "test"
CST [15788] STATEMENT: update test set value = 'tyyu' where id =3;
CST [15786] LOG: duration: 12131.851 ms
查看上面的日志
通过上面的日志给出的信息 process 15788 检测到死锁，在20秒的时候，（20003.487）15788 等 待sharelock 锁，而process 15788 被 15786 kill 掉。在最后踢掉的过程中， 15788 的语句是 update test set value = 'tyyu' where id =3; 15786 的语句是
update test set value = 'tyyu' where id =2;
在PG 中有行锁和表锁两种，每行记录都有xmax， 如果一个事务要处理这一行会在 XMAX 上添加 transaction_ID, 如果这样一行已经有了 transaction_id 则要再次添加事务ID 的事务就需要等待。而当要进行UPDATE 和 DELETE 操作的过程中会检查相关行的 XMAX 的状态。
通过判断XMAX 的状态来，这条记录可以被UPDATE 或者 DELETE 还是不能。这也是POSTGRESQL 和别的数据库比较没有UNDO 这个空间的设置原因之一，因为不需要。
说完简单的分析，还的找一期来说说，怎么避免死锁。
