archive_mode=on是物理复制的必要非充分条件，必须配合可用的archive_command；wal_level决定wal记录粒度，物理复制需replica及以上，逻辑复制必须logical，二者职责分明不可混淆。
archive_mode 开启后不等于能做物理复制
物理复制依赖的是 WAL 日志的完整归档和连续性，archive_mode 只是把 WAL 文件拷出去，但不保证 WAL 生成策略满足流复制要求。比如设成 on 却没配 archive_command，或者命令执行失败但没监控，WAL 就堆积在 pg_wal/ 里不归档，备库断连后无法追赶。
常见错误现象：pg_stat_archiver 视图中 last_failed_time 非空、failed_count 持续增长；主库 pg_wal/ 目录体积暴涨。
-
archive_mode = on是必要条件，不是充分条件；必须搭配可用的archive_command（如cp %p /backup/wal/%f）且确保目标路径可写、有空间 - 物理复制场景下，建议同时开启
archive_mode = on和max_wal_senders > 0，否则流复制中断时无 fallback 路径 - 归档延迟会影响 PITR 精度，若
archive_timeout设得过大（如 3600），可能丢失最近一小时的 WAL，导致恢复点不准
wal_level 决定 WAL 记录的“信息密度”
wal_level 不是开关，而是分级记录策略：值越低，WAL 越“瘦”，越省磁盘和网络带宽，但支持的功能越少。逻辑复制必须用 logical，物理复制最低只需 replica（9.6+ 之后 hot_standby 已废弃）。
使用场景差异明显：只做主从流复制？wal_level = replica 够用；要建逻辑订阅或使用 Debezium？必须 logical，且主库需额外加载 pgoutput 和 logical decoding 支持。
-
wal_level = replica：记录足够支撑物理备库回放，不包含行级变更细节，不能用于逻辑解码 -
wal_level = logical：额外记录 tuple 的完整镜像（full行级快照）和事务边界，开销明显增大，尤其高 UPDATE 频率表 - 改
wal_level必须重启 PostgreSQL，不能 reload；升级前务必确认所有下游消费者（如逻辑订阅端）兼容新格式
逻辑复制依赖 wal_level=logical + publication/subscriptions，和 archive_mode 无关
逻辑复制走的是独立通道：它靠后台进程读取 WAL 并解码为逻辑变更消息，再通过 pgoutput 协议发给订阅端。整个过程不碰归档文件，也不依赖 archive_mode 是否开启。
容易踩的坑是误以为“开了归档就能逻辑复制”，结果发现 CREATE PUBLICATION 报错：ERROR: logical replication requires wal_level >= logical——这时翻 archive_mode 配置毫无意义。
- 逻辑复制唯一强依赖是
wal_level = logical，其他如max_replication_slots、max_worker_processes属于配套资源项，非核心开关 - 逻辑复制不保证事务原子性跨库传播，例如一个事务更新 5 张表，只有部分表被发布，订阅端看到的就是分批发出的变更
- 如果主库曾设过
wal_level = replica并运行了一段时间，切到logical后，旧 WAL 中没有逻辑解码所需信息，新建的 publication 无法从历史位置开始同步
物理复制对 wal_level 和 archive_mode 的组合要求更刚性
物理复制本质是字节级重放 WAL，所以既需要 WAL 足够“全”（wal_level >= replica），也需要 WAL “不断供”（archive_mode = on + 可靠 archive_command）。两者缺一不可，且配置错误会直接阻断启动。
典型报错：FATAL: could not connect to the primary server: FATAL: no pg_hba.conf entry for replication connection —— 这其实是表象，真正卡点常在 WAL 不可用：备库 fetch 到某个 WAL 文件名后，在归档路径里找不到对应文件，日志里沉默失败，只显示连接超时。
- 物理复制中，
wal_level = replica是底线，archive_mode = on是安全冗余；生产环境强烈建议两者都开 -
archive_command中避免使用可能阻塞的命令（如带ssh的远程拷贝未设超时），否则主库 WAL 清理会被挂起，pg_wal/填满后整个实例 hang 住 - 使用
pg_basebackup初始化备库时，若主库wal_level不足，备份本身能完成，但后续流复制必然失败——这个坑往往在切换后几小时才暴露
