pg_basebackup 报 max_wal_senders，单机备份为何也需要复制连接

只有一台 PostgreSQL，没有备用节点，pg_basebackup 却报复制连接不够：

FATAL: number of requested standby connections exceeds max_wal_senders (currently 0)

如果错误出现在关闭 WAL 归档之后，先看是否同时把 wal_level 改成了 minimal、把 max_wal_senders 改成了 0。pg_basebackup 在服务器运行期间制作物理备份，使用复制协议连接数据库；即使备份文件就在本机，也需要 WAL sender。

关闭归档，不必关闭备份使用的复制能力

archive_mode 控制 WAL 归档，wal_level 决定 WAL 记录的信息级别，max_wal_senders 限制同时运行的 WAL sender。这三项关联，但不能一起按“单机不需要复制”处理。

wal_level = minimal 不适合这条在线物理备份路径。继续使用 pg_basebackup 时，保留满足备份要求的 WAL 级别，通常为 replica；已经使用逻辑复制的实例不能为了备份把 logical 降为 replica。

下面是配置关系示例，不是所有实例的推荐值：

archive_mode = off
wal_level = replica
max_wal_senders = 10

关闭归档会改变归档恢复及时间点恢复条件。已有的备份方案如果依赖连续归档 WAL，应先确认保留与恢复链，不能只因归档目录占空间就停用它。保留 replica 也不会自动清理旧归档文件。

需要几个 WAL sender，取决于实际备份参数

备份本身至少需要一个 WAL sender。使用 -X stream 时，还会另开一条连接并行接收 WAL；这是 PostgreSQL 14、18 的默认 WAL 收集方式。同一时刻的其他备份和备用节点也会占用名额。

所以只把上限从 0 改成 1，仍可能在备份开启 WAL 流时失败。先从任务日志、脚本或调度配置中确认实际参数，再按同时运行的任务和副本连接安排容量。不要为了省一个名额随意改用 -X none：这种模式要求另有可靠途径取得恢复所需 WAL。

以下 SQL 读取当前实例的设置和 WAL sender。应在备份实际连接的服务器上执行，并使用有足够统计可见权限的账户：

SELECT current_database(), current_setting('server_version');
SHOW wal_level;
SHOW archive_mode;
SHOW max_wal_senders;

SELECT pid, usename, application_name, client_addr, state
FROM pg_stat_activity
WHERE backend_type = 'walsender';

失败之后查到零条 WAL sender，不能证明失败瞬间没有连接占用。对照任务时间、并发备份与服务器日志；权限不足时，也不能把看不到会话详情当作会话不存在。

max_replication_slots 管的是复制槽数量。报错明确指向 max_wal_senders 时，增加复制槽上限不能替代修复 WAL sender 的容量。普通应用的 too many clients 则应另查整个实例的客户端连接预算。

更改设置后，确认服务器真正使用了新值

wal_level、max_wal_senders 和 archive_mode 都是需要服务器重启才能生效的设置。修改前保存配置，核对容器参数、启动命令与配置文件的覆盖关系，安排维护窗口。只执行配置重载不会让这些新值生效。

重启后再次查询实际设置，然后从原来的备份调度入口检查任务结果。应核对退出码、备份产物及所需 WAL，并在隔离环境完成相应恢复验证；仅有备份目录或连接错误消失，不能证明这份备份能恢复。

如果改动影响业务，按保存的配置回退并执行所需重启。回退成 wal_level = minimal、max_wal_senders = 0 会再次阻断这条备份路径，不能把数据库能启动与备份恢复可用混为一谈。