Postgres 超时 (Timeout) 详解
原文地址 https://www.bytebase.com/blog/postgres-timeout/
PostgreSQL 提供各种超时 (Timeout) 设置,通过控制某些进程的持续时间来帮助管理和优化数据库操作。这些超时对于确保系统的稳定性和性能至关重要,尤其是在高流量或复杂查询的环境中。让我们一一回顾。
(一) 语句超时 (statement_timeout)
statement_timeout 设置了单个查询允许执行的最长时间限制。如果查询超过了这个时间限制,PostgreSQL 将自动终止查询并返回错误信息。
ERROR: canceling statement due to statement timeout 错误:由于语句超时而取消语句 如果单个 simple-Query 消息中出现多个 SQL 语句,则超时将分别应用于每个语句。statement_timeout 可有效防止长时间运行的查询占用过多资源或导致数据库出现性能问题。
(二) 锁超时 (lock_timeout)
lock_timeout 控制一个事务为获得数据库对象(如表或行)上的锁而等待的时间,然后才会放弃并返回错误。
ERROR: canceling statement due to lock timeout 错误:由于锁超时而取消语句 在 Postgres 中,等待获取资源锁的事务会阻塞需要在同一资源上获取冲突锁的传入事务。对于获取重量级锁(如运行 DDL 语句)的事务,建议设置 lock_timeout。常见的做法是创建一个单独的 Postgres 用户来运行 DDL,并为该用户设置一个较短的 lock_timeout。
ALTER ROLE ddl_user SET lock_timeout = 10000; -- 10 秒
(三) 事务会话空闲超时 (idle_in_transaction_session_timeout) idle_in_transaction_session_timeout 控制会话在事务中空闲的最长时间。如果会话在事务中的空闲时间超过指定的超时时间,PostgreSQL 将自动终止会话并回滚正在进行的事务。 ERROR: terminating connection due to idle-in-transaction timeout 错误:由于事务中的空闲超时而终止连接 假设您有一个应用程序,在等待用户输入或执行一些与数据库无关的处理时,偶尔会让事务处于进行状态。如果一个事务处于进行和空闲状态的时间过长,它可能会持有表或行上的锁,从而阻止其他事务访问这些资源。通过设置 idle_in_transaction_session_timeout 可以自动终止这些空闲会话,确保资源不会被不必要地占用。即使没有重要的锁,一个进行中的事务会阻止清理( vacumm)已经被删除,但在当前事务仍然可见的元组;因此,长时间处于空闲状态会导致表膨胀。 图片 空闲会话超时 (idle_session_timeout)
idle_session_timeout 控制会话在被自动终止前的最长空闲时间。与 idle_in_transaction_session_timeout 不同的是,idle_session_timeout 只适用于在事务中处于空闲状态的会话,而 idle_session_timeout 则适用于任何处于空闲状态的会话,无论它是否在事务中。 ERROR: terminating connection due to idle session timeout 错误:由于空闲会话超时而终止连接 在使用连接池或其他中间件时要小心,因为这样的层可能不会对意外的连接关闭做出很好的反应。好的做法是为交互式处理创建一个单独的 Postgres 用户,并相应地设置 idle_session_timeout。 ALTER ROLE interactive_user SET idle_session_timeout = 600000; -- 10 分钟
(四) 事务超时 (transaction_timeout)
(五) 即将发布的 Postgres 17 版本将引入新的 transaction_timeout。从文档中可以看到 在一个事务中终止任何超过指定时间的会话。该限制既适用于显式事务(以 BEGIN 开始),也适用于与单条语句相对应的隐式事务。 一个典型的网络服务由 3 个主要部分组成: 网络服务器 应用程序服务器 数据库服务器
为防止长时间连接,通常会在网络服务器和应用程序服务器上设置连接超时。当网络服务器/应用服务器已经终止连接时,再处理事务就太浪费了。在引入事务超时(transaction_timeout)之前,没有防止长时间事务的可靠方法。即使同时设置了 statement_timeout 和 idle_in_transaction_session_timeout,如果事务是由短语句和中间的短暂停顿组成的,那么该事务仍然是开放的。 你可能想知道,为什么 PostgreSQL 花了这么长时间才推出一个直接的事务超时功能 -- 迟到总比不到好 😁!顺便说一句,MySQL 也没有这个功能 😜。
参考资料: 官方文档 (https://www.postgresql.org/docs/current/runtime-config-client.html) pgsql-hackers 关于引入 transaction_timeout 的讨论 (https://www.postgresql.org/message-id/flat/f508267d1ba8f0bfd7b93181d10511dc%40oss.nttdata.com#2506da45ff92aaea65c30996fbf19c85)
💡 更多资讯,请关注 Bytebase 公号:Bytebase

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
GaussDB关键技术原理|高可用:两地三中心跨Region容灾
接上篇GaussDB关键技术原理|高可用:逻辑复制从逻辑复制方面对GaussDB的高可用能力进行了介绍,本篇将从两地三中心跨Region容灾方面继续解读GaussDB高可用技术。 4 两地三中心跨Region容灾 4.1 概述 两地三中心,顾名思义,两地指的是两座城市,即同城和异地,三中心指的是生产中心,同城容灾中心以及异地容灾中心。近年来,国内外频繁出现自然灾害,以同城双中心加异地灾备中心的"两地三中心"的灾备模式也随之出现,这一方案兼具高可用性和灾难备份的能力。 同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心,双中心具备基本等同的业务处理能力并通过高速链路实时同步数据,日常情况下可同时分担业务及管理系统的运行,并可切换运行;灾难情况下可在基本不丢失数据的情况下进行灾备应急切换,保持业务连续运行。 异地灾备中心是指在异地的城市建立一个备份的灾备中心,用于双中心的数据备份,当双中心出现自然灾害等原因而发生故障时,异地灾备中心可以用备份数据进行业务的恢复。数据库实例之间借助存储介质或者不借助存储介质直接实现数据的全量和增量同步。当主数据库实例(即生产数据库实例)出...
- 下一篇
凌鲨 0.9.7 版本更新
2024年08月15日 软件下载地址 服务端版本: 0.3.5 新增: 本地仓库卡片上增加项目关联信息 改进: 工作台当前待办从浮层改成标签页 改进: 我的工作记录增加记录详情入口 改进: 调整我的工作快捷键 改进: 项目重点内容页面隐藏创建内容按钮 修复: 修复服务器地址匹配不正确的问题 相关截图
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路