背景

1、产品的问题点

• PG 不支持打印慢SQL锁等待信息

• • 实际上log_min_duration, auto_explain, pg_stat_statements都没有统计SQL的锁等待时长.

2、问题点背后涉及的技术原理

• log_min_duration, 执行时长超过这个值的SQL会被打印到日志中, 但是日志中并不会记录这条SQL的锁等待耗时.
• auto_explain 插件可以用于打印执行时间超过auto_explain.log_min_duration时长的SQL, 包括其执行计划, NODE的执行时间等. 但是锁等待的耗时算在整个SQL,不会单独统计.
• log_lock_waits 会记录超出锁等待时长超过deadlock_timeout的会话和事务, 但是不打印sql, 而且每隔deadlock_timeout时间打印一条, 很难汇总统计.

3、这个问题将影响哪些行业以及业务场景

• 通用

4、会导致什么问题?

• 分析因为锁等待导致的问题非常麻烦, 而且锁等待通常是业务逻辑导致的问题, 这样需要引入开发者一起来进行分析下. 分析问题的门槛高.

5、业务上应该如何避免这个坑

• 暂无很好的解决方案, 只能经常采集pg_locks, pg_stat_activity的动态视图信息, 进行等待统计.

• • 《PostgreSQL 活跃会话历史记录插件 - pgsentinel 类似performance insight \ Oracle ASH Active Session History》
  • 《PostgreSQL Oracle 兼容性之 - performance insight - AWS performance insight 理念与实现解读 - 珍藏级》

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 管理复杂度增加

7、数据库未来产品迭代如何修复这个坑

• 希望内核层面在log_min_duration 和 auto_explain 记录的SQL中记录锁等待的时长,
• 同时希望 log_lock_waits 可以把同一个请求到锁等待日志汇总到一起, 包括SQL信息, 堵塞信息等便于分析.