PostgreSQL中的死锁和锁等待

 

开始之前明确一下死锁和锁等待这两个事件的异同
相同的之处：两者都是当前事物在试图请求被其他事物已经占用的锁，从而造成当前事物无法执行的现象
不同的之处：死锁是相关session双方或者多方中必然要牺牲（回滚）至少一个事务，否则双方（或者多方）都无法执行；锁等待则不然，对于暂时无法申请到的锁，尝试持续地“等待一段时间”，这个等待的时间就是“锁等待”参数决定，超出之后就不等了。 当事物锁等待超时后，当前事物已经持有的锁如何处理，是一个非常考究的问题，
对于MySQL来说，可以选择回滚整个事务，或者是仅回滚当前锁超时的语句，具体参考这里：https://www.cnblogs.com/wy123/p/12724252.html
下文对Postgresql中锁超时之后当前Session中事务和语句的处理进行一个验证。

Postgresql的死锁检测机制

锁等待有可能是发展成死锁，也有可能不是死锁，可能继续等待一段时间之后就可以正常申请到所需要的锁了。
发生死锁的情况下，一定会产生锁等待，因为此时的锁等待继续下去没有任何意义，所以必须（立刻）牺牲其中一个事务，MSSQL和MySQL都是类似的处理机制。
没有死锁等待时间一说，因为一旦死锁的条件生成，则没有任何缓冲的余地，必须至少牺牲（回滚）其中一个事物，释放其占用的锁，来打断这个死锁的闭环。
但在MySQ中有一个死锁自动检测开关，可以打开或者关闭这个自动的死锁检测与解除机制，默认是打开的。
但是在Postgresql中，有一个死锁等待事件的参数，默认是1s中，也就是是说Postgresql后台进程会以1s的频率来检测是否存在死锁。

换句话说就是，在Postgresql的死锁检测机制中，不是以MySQL中那种实时监测方式来处理死锁的。为什么postgresql中对于死锁要以类似于定时轮训的方式来实现死锁检测而不是实时监测？

回答这个问题之前，先回到MySQL中：
上面提到MySQL中的死锁自动检测机制是有一个开关的，当然这个开关是可以关闭的，也就是系统不检测死锁信息，那么在死锁发生后也就无法自动牺牲其中一个事务。
那为什么还要允许这个开关设置为关闭呢？其实死锁检测也是需要代价的，尤其是实时监测，参考这里：https://mp.weixin.qq.com/s/Lc_tQEK55r_syapebSu0Cg，提到过通过关闭死锁检测来提升性能的最佳实践。

然后回到Postgresql中：
在Postgresql中，deadlock_timeout是进行死锁检测之前在一个锁上等待的总时间（以毫秒计）。Postgresql的理念中认为死锁检测代价是比较高的，因此服务器不会在每次等待锁时都判断有没有形成死锁。我们乐观地假设在生产应用中死锁是不常出现的，并且只在开始检测死锁之前等待一会儿。增加这个值就减少了浪费在无用的死锁检测上的时间（频率），但是降低了报告真正死锁错误的速度。默认是 1 秒（1s），这可能是实际中你想要的最小值。在一个高负载的服务器上，你可能需要增大它。这个值的理想设置应该超过你通常的事务时间，这样就可以减少在锁释放之前就开始死锁检查的机会。同理，对于高并发小事务处理系统上，默认的1秒已经足够了。只有超级用户可以更改这个设置。
参考:https://postgresqlco.nf/zh/doc/param/deadlock_timeout/

Postgresql锁超时

Postgresql中同样可以设置所等待的超时时间，意味着当前事务在请求一个锁的时候，一旦等待时长超出指定的时间，当前语句被中止。
该参数的默认值为0，意味着发生锁等待的时候永远不超时，一直等待下去。

与statement_timeout不同，这个超时只在等待锁时发生。注意如果statement_timeout为非零，设置lock_timeout为相同或更大的值没有意义，因为事务超时将总是先与锁超时触发。

官网说不推荐在postgresql.conf中设置lock_timeout，因为它会影响所有会话。
实际这个建议值得商榷，如果不设置lock_timeout，一个Session的锁等待将无限拉长（如果statement_timeout不限制的话），一旦大量的连接涌入进来等待一个短时间内无法释放的不兼容锁，那么数据库的连接数可能在短时间内被打爆，影响一些正常的连接。这里认为应该根据系统中事务轻重程度，设置成超过deadlock_timeout且小于statement_timeout的一个值，强制一些超锁等待超时的Session自动终止，不要无限期等待而占用数据库连接，引发系统级的异常。

Postgresql中的锁超时后事务的处理

相比MySQL给予了用户充分的自由，在超等待超时后，可以选择设置回滚当前语句，或者回滚整个事务（参数innodb_rollback_on_timeout决定），Postgresql中是如何处理的呢？

可以创建一个死锁Session，当前事务作为牺牲品牺牲之后，出现current transaction is aborted, commands ignored until end of transaction block
当前Session作为牺牲品之后，回滚的是整个事务，这个容易理解

对于锁超时之后当前Session的情况呢，设置一个锁超时的时间

制造一个锁超时的场景，锁超时之后，当前Session的任何语句都会被回滚，即便是执行一个commit，当前Session锁超时后的Session状态，虽然还是一个活动事务，但能且只能回滚。

锁超时之后的Session状态

可见，默认情况下，Postgresql在当前Session锁超时之后，会回滚整个事务，而不是当前语句，这样其实更加的科学合理，MySQL也是这么建议的。

最后，Postgresql中的deadlock_timeout，设置成不同的值，一方面取决于业务，另外一方面，对系统整体的性能影响，该如何科学地衡量？