PostgreSQL12版本预览：分离max_wal_senders和max_connections的连接槽处理

作者

digoal

日期

2019-03-09

标签

PostgreSQL, max_wal_senders, max_connections, 连接槽管理

背景

在 PostgreSQL 中，流复制功能依赖于 wal sender 进程来传输写前日志（WAL）。这些进程用于支持物理复制、逻辑复制以及 pg_basebackup 备份等操作。每个使用流协议的连接都需要一个 wal sender 进程。

在 PostgreSQL 12 之前的版本中，max_wal_senders 参数是计入 max_connections 的。这意味着，如果普通用户连接占用了所有可用的连接槽，流复制连接可能会因为没有足够的 wal sender 进程而失败。

为了解决这一问题，PostgreSQL 12 将 max_wal_senders 参数独立出来，不再计入 max_connections。这样，普通连接和流复制连接之间就不会互相干扰。

此外，从节点（standby）的 max_wal_senders 参数必须大于或等于主节点（primary）的 max_wal_senders 参数，以确保从节点能够处理所有来自主节点的流复制连接。

相关提交：https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ea92368cd1da1e290f9ab8efb7f60cb7598fc310

```
将 max_wal_senders 从 max_connections 中分离出来，独立管理连接槽

自 max_wal_senders 引入以来，在计算可用于复制连接的连接槽数量时，它一直被计入 max_connections。这可能导致一些用户在其他后端会话已被应用程序占用的情况下，无法进行基线备份或复制。超级用户专用连接槽并不是解决此问题的正确方法。

此次提交使 max_wal_senders 在处理 PGPROC 条目时独立于 max_connections，意味着 wal sender 连接槽将使用自己的空闲队列进行管理，类似于自动清理工作进程和后台工作进程。

这一变更带来的兼容性问题是，从节点现在需要具有至少等于其主节点的 max_wal_senders 值。因此，如果从节点的 max_wal_senders 设置低于主节点，可能会导致故障转移失败。不过，通常情况下这不会成为问题，因为从节点的设置通常继承自主节点，postgresql.conf 文件通常会在基线备份过程中被复制，确保参数的一致性。
```

参考

《PostgreSQL 拒绝服务DDOS攻击与防范》

PostgreSQL 许愿链接

您的愿望将传达给 PG 内核开发者、数据库厂商等，帮助提高数据库产品的质量和功能。针对非常好的提议，奖励限量版 PG 文化衫、纪念品、贴纸、PG 热门书籍等，奖品丰富，快来许愿吧！

9.9元购买3个月阿里云 RDS PostgreSQL 实例

PostgreSQL 解决方案集合

德哥 / digoal's github - 公益是一辈子的事.