标签
PostgreSQL , max_wal_senders , max_connections , sorry, too many clients already
背景
如果你需要使用PG的流复制，上游节点的max_wal_senders参数，用来限制这个节点同时最多可以有多少个wal sender进程。
包括逻辑复制、物理复制、pg_basebackup备份等，只要是使用stream protocol的连接，每个连接都需要一个wal sender进程，与之建立stream protocol通讯。
在12的版本以前，max_wal_senders是算在max_connections里面的，也就是说，如果用户的普通连接把数据库连接占光了，流复制连接也会不够用。
12修正了这个问题，max_wal_senders参数独立控制，不算在max_connections里面。普通连接与流复制连接相互不再干扰。
同时要求standby节点的max_wal_senders参数，必须大于或等于primary（上游）数据库的max_wal_senders参数。 与要求standby节点的max_connections参数，必须大于或等于primary（上游）数据库的max_connections参数一样。
Move max_wal_senders out of max_connections for connection slot handling
Since its introduction, max_wal_senders is counted as part of
max_connections when it comes to define how many connection slots can be
used for replication connections with a WAL sender context. This can
lead to confusion for some users, as it could be possible to block a
base backup or replication from happening because other backend sessions
are already taken for other purposes by an application, and
superuser-only connection slots are not a correct solution to handle
that case.
This commit makes max_wal_senders independent of max_connections for its
handling of PGPROC entries in ProcGlobal, meaning that connection slots
for WAL senders are handled using their own free queue, like autovacuum
workers and bgworkers.
One compatibility issue that this change creates is that a standby now
requires to have a value of max_wal_senders at least equal to its
primary. So, if a standby created enforces the value of
max_wal_senders to be lower than that, then this could break failovers.
Normally this should not be an issue though, as any settings of a
standby are inherited from its primary as postgresql.conf gets normally
copied as part of a base backup, so parameters would be consistent.
参考
免费领取阿里云RDS PostgreSQL实例、ECS虚拟机
