Database 为什么Postgres从9.4开始对ALTER TABLE ADD COLUMN语句强制执行访问独占锁？

我对postgres中

altertableaddcolumn

的最初理解是，如果只添加一个简单的新列（即没有默认值、没有索引、没有非空验证等），那么就没有锁定

然而，从9.4开始，这似乎不再是事实：

在9.4文档中，它说

除非明确说明，否则将保持访问独占锁。什么时候 列出了多个子命令，持有的锁将是最严格的 任何子命令都需要一个

而9.3中却没有这样的东西

在实践中，9.4似乎更可能在表有大量通信量时触发死锁——但不完全确定为什么会这样。理论上，事务隐式地在表上持有一个

行排他

锁，然后当语句执行时，它会升级为

访问排他

，但这同样只是一个理论

---

问题是：是什么改变了设计？现在为高流量的表添加列的正确方法是什么？

我刚刚用PostgreSQL 9.2进行了测试，它应该使用

访问独占锁

锁只会保持很短的时间，但如果有大量并发活动（特别是长操作），则可能会出现明显的挂起，事务会堆积在等待长事务完成的
访问独占
锁请求后面

文档中的差异是由于PostgreSQL commit改进了文档，而具有讽刺意味的是，降低了某些
ALTER TABLE
子命令所需的锁级别

尽可能减少PostgreSQL中锁的数量和严重性是一项持续的工作。
为什么这会增加死锁的可能性？您是否正在使用在多个表上以不同顺序运行ALTER TABLE语句的多个事务？它可能会增加锁等待，但我看不出这是如何导致死锁的。@NSF我可以问一下这个问题的基础是什么，您是否经历过死锁，在这种情况下，您是否找到了原因？