复制 · XB 现场笔记

Postgres 流式复制让备用节点保持温热

Tue, 10 Aug 2027 00:00:00 +0000

物理流复制把 PostgreSQL WAL 发送到备库，备库通过重放记录维持集群的另一份副本。发送不必等待整个日志段结束。这与选择部分表变更进行传送的逻辑复制不同。接收进程正在运行、备库可以连接，都是有价值的健康信号，但任何一个信号都不能单独证明某条已经提交的业务记录此刻在备库可见。

坏掉的样子

流复制默认是异步的。主库可以先向客户端确认提交，备库之后才收到或应用相关记录。若主库恰好在这个窗口丢失，切换到备库时可能丢掉最近已经确认的工作。备库也可能保持连接并持续接收日志，却由于暂停回放而一直返回旧行。因此网络交付在推进，并不能证明查询新鲜度也在推进。

应区分不同进度标记。备库的接收位置函数报告通过流复制已经接收并同步到磁盘的位置，回放位置函数则报告已经应用的位置，两者差值可以暴露回放积压。最后一次重放事务的时间戳，即使在完全空闲的系统上也会不断变旧；单纯用当前时间减去它，不能可靠判断究竟有多少尚未处理的工作。

快速验证

使用非超级操作系统账户，在 Linux 环境中准备 PostgreSQL 18 服务端与客户端程序。原文记录了 PostgreSQL 18.6 执行结果，本轮未重跑。它创建私有临时集群及 Unix 套接字目录，不打开 TCP 监听，但 Unix 套接字仍是监听端点，必须得到执行环境允许。本地信任认证仅用于这些可丢弃的实验实例。少量日志预留支持这个有界演练，脚本没有配置永久复制槽。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-streaming.XXXXXX)
mkdir "$lab/socket"
primary=$lab/primary
standby=$lab/standby
cleanup() {
 for cluster in "$standby" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_wal_senders = 4
wal_keep_size = '64MB'
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE marker (id integer PRIMARY KEY,value text);
INSERT INTO marker VALUES (1,'base');
SQL
pg_basebackup -D "$standby" -R -X stream -c fast -w
cat >> "$standby/postgresql.conf" <<CONF
port = 56433
hot_standby = on
CONF
pg_ctl -D "$standby" -l "$lab/standby.log" -w -t 15 start >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_pause()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_get_wal_replay_pause_state()='paused'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || { echo 'replay did not pause' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c "INSERT INTO marker VALUES (2,'later')"
target=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_current_wal_lsn()')
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'receiver did not catch up' >&2; exit 1; }
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT state,sync_state FROM pg_stat_replication'
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<SQL
SELECT pg_last_wal_receive_lsn()>='$target'::pg_lsn,
 pg_last_wal_replay_lsn()<'$target'::pg_lsn,
 (SELECT count(*) FROM marker);
DO \$\$ BEGIN
 IF (pg_last_wal_receive_lsn()>='$target'::pg_lsn
 AND pg_last_wal_replay_lsn()<'$target'::pg_lsn
 AND (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)='1:base')
 IS NOT TRUE THEN
 RAISE EXCEPTION 'paused replay result mismatch';
 END IF;
END \$\$;
SQL
echo stale_read_while_receiving
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_resume()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_replay_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || { echo 'replay did not catch up' >&2; exit 1; }
 sleep 0.1
done
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF (SELECT string_agg(id||':'||value,',' ORDER BY id) FROM marker)
 IS DISTINCT FROM '1:base,2:later' THEN
 RAISE EXCEPTION 'resumed replay result mismatch';
 END IF;
END $$;
SQL
pg_ctl -D "$primary" -m fast -w stop >/dev/null
echo old_primary_stopped
pg_ctl -D "$standby" -w -t 15 promote >/dev/null
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT pg_is_in_recovery();
INSERT INTO marker VALUES (3,'promoted');
SELECT id,value FROM marker ORDER BY id;
DO $$ BEGIN
 IF pg_is_in_recovery() OR (SELECT count(*) FROM marker)<>3 THEN
 RAISE EXCEPTION 'promotion result mismatch';
 END IF;
END $$;
SQL
printf 'lab_directory %s\n' "$lab"

脚本通过带恢复配置选项的物理基础备份建立副本，这个选项会写入备库连接信息并创建备库信号文件。副本在另一个套接字端口启动后，先请求暂停回放，再等待状态确实变成已经暂停。随后主库提交第二行，并捕获提交之后的日志位置，作为接收与回放比较的明确目标。

主库的预期状态是正在流复制且采用异步确认。备库输出的两个真值与行数一，分别表示接收已经到达目标、回放仍未到达、表里只有原始一行。断言还会检查这一行的实际内容。因此“仍在接收时读到旧数据”的标记来自数据库真实查询结果，并不是在应用缓存中人为伪造一段延迟。

恢复回放之后，脚本等待回放位置达到目标，再核对第一行为 base、第二行为 later。每次观察都使用新连接，排除了先前打开的事务快照导致旧结果的干扰。真实应用中的长事务如果继续持有旧快照，即使备库已经回放到新位置，也可能还需要结束那个事务才能读到新版本；这是另一条需要单独识别的可见性边界。

接管步骤先停止旧主库，再提升备库并等待提升完成。恢复状态变为假，第三行写入后得到 promoted，断言验证新主库确实接受了这次写入。所有实验服务都会在退出时停止，打印目录保留日志。这验证的是隔离环境里的有序提升，没有验证自动故障探测、网络分区处理或客户端地址迁移，不能据此宣称整套高可用切换已经完成。

明确确认与保留契约

同步复制既需要选择同步备库，也需要相关事务同步提交设置。仅把事务选项设为开启，而没有选择任何同步备库，不会凭空增加远端确认要求。配置好同步备库之后，普通开启模式等待它们持久化日志；远端写入模式等待写入对方操作系统；远端应用模式等待对方重放。这些选择改变的不只是持久性与读取可见性，也包括提交延迟以及备库不可用时的服务可用性。远端应用确认只覆盖参与确认的备库，不覆盖负载均衡器后面的所有副本；随后把读取送到别处，仍可能返回旧数据。

日志保留是另一项独立义务。复制槽可以保留断线接收者仍需要的日志，但消费者长期停滞时，若没有有意识地设置限制与监控，也可能耗尽磁盘。没有足够保留日志或可用归档时，过旧的备库可能只能重建。应联合观察日志生成、接收、回放、保留字节数与剩余空间，不要只看某一个复制进程是否还活着。

提升本身不会隔离另一个仍然写入的主库。生产故障切换必须阻止旧写入者继续服务，选择可接受的恢复位置，重定向客户端，并通过受支持的重建或回绕流程让原主库重新加入。否则两个独立写入者可能产生分叉。一个健康的流复制连接只证明其中一部分机制正在工作，不能替代完整接管流程及其业务数据核验。

来源

PostgreSQL 18 温备与流复制，异步交付、同步确认、日志保留与故障切换，已核验 2026-10-15。
PostgreSQL 18 管理函数，接收和回放位置、实际暂停状态及提升语义，已核验 2026-10-15。
PostgreSQL 18 pg_basebackup，使用恢复配置选项创建备库，已核验 2026-10-15。

只读副本服务查询需求

Mon, 12 Jul 2027 00:00:00 +0000

只读副本允许一份数据库服务查询，另一份数据库处理写入。报表、搜索或其他适合的读取，可以由此离开写入节点，但把连接路由到某个地址只是设计的一部分。应用还必须说明返回结果需要包含哪些已经提交的变更。本文采用 PostgreSQL 物理热备库，它在正常恢复模式下可以读取，但不能接受普通业务写入。

坏掉的样子

异步复制下，成功写入之后立刻查询副本，仍然可能读到旧值。用户刚修改账户并刷新页面，之前的内容却又出现了。此时副本可能连接健康、日志接收持续推进，只是相关提交还没有被重放。如果新鲜度检查只看接收位置、不看回放位置，就检查了错误的完成边界。

即使回放已经推进，旧事务快照仍然可能影响结果。可重复读事务本来就需要在恢复继续进行时保留自己的视图。等待副本应用某次写入，不会顺便刷新这个事务。因此，要实现写后读到本次修改，既需要足够的回放进度，也需要查询使用在这个进度条件满足之后取得的新快照，两个条件缺一不可。

新鲜度承诺也需要限定范围。包含这个用户较早的一次写入，不等于保证其他地方不存在更新的事务。若读取余额是为了批准下一笔扣款，仍然必须在写入路径中进行事务性核对。副本提供的查询容量，不能替代保护业务动作的并发控制，也不能使一个只读结果天然变成后续写入的有效授权。

快速验证

在 Linux 环境中以非超级操作系统账户运行脚本，并准备 PostgreSQL 18 服务端和客户端程序。本次使用 PostgreSQL 18.6。脚本建立私有主备集群，通过 Unix 套接字连接，不打开网络监听。一个命名管道保持读会话存活，让实验能够明确控制事务快照边界，无需额外安装数据库驱动。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-read-replica.XXXXXX)
mkdir "$lab/socket"
primary=$lab/primary
standby=$lab/standby
reader_pid=''
reader_open=0
cleanup() {
 if test "$reader_open" = 1; then exec 3>&-; fi
 if test -n "$reader_pid"; then wait "$reader_pid" || :; fi
 for cluster in "$standby" "$primary"; do
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
 done
}
trap cleanup EXIT
initdb -D "$primary" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$primary/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
wal_keep_size = '64MB'
CONF
pg_ctl -D "$primary" -l "$lab/primary.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
CREATE TABLE account (id integer PRIMARY KEY,balance integer);
INSERT INTO account VALUES (1,100);
SQL
pg_basebackup -D "$standby" -R -X stream -c fast -w
cat >> "$standby/postgresql.conf" <<CONF
port = 56433
hot_standby = on
CONF
pg_ctl -D "$standby" -l "$lab/standby.log" -w -t 15 start >/dev/null
mkfifo "$lab/reader.sql"
PGPORT=56433 PGAPPNAME=replica_snapshot psql -X -v ON_ERROR_STOP=1 -qAt <"$lab/reader.sql" >"$lab/reader.log" 2>&1 &
reader_pid=$!
exec 3>"$lab/reader.sql"
reader_open=1
printf '%s\n' 'BEGIN ISOLATION LEVEL REPEATABLE READ;' 'SELECT balance FROM account WHERE id=1;' >&3
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT EXISTS (SELECT FROM pg_stat_activity WHERE application_name='replica_snapshot' AND state='idle in transaction' AND backend_xmin IS NOT NULL)")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_pause()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_get_wal_replay_pause_state()='paused'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt -c 'UPDATE account SET balance=80 WHERE id=1'
target=$(psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_current_wal_lsn()')
printf 'primary_balance '
psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT balance FROM account WHERE id=1'
printf 'paused_replica_balance '
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT balance FROM account WHERE id=1'
for attempt in 1 2 3 4 5; do
 test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_replay_lsn()>='$target'::pg_lsn")" = f
 sleep 0.1
done
echo fresh_read_gate_timed_out
PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT pg_wal_replay_resume()' >/dev/null
attempt=0
while test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_last_wal_replay_lsn()>='$target'::pg_lsn")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 150 || exit 1
 sleep 0.1
done
test "$(PGPORT=56433 psql -X -v ON_ERROR_STOP=1 -qAt -c 'SELECT balance FROM account WHERE id=1')" = 80
echo fresh_snapshot_after_replay_80
printf '%s\n' 'SELECT balance FROM account WHERE id=1;' 'COMMIT;' >&3
exec 3>&-
reader_open=0
wait "$reader_pid"
reader_pid=''
test "$(cat "$lab/reader.log")" = "$(printf '100\n100')"
echo old_repeatable_read_snapshot_still_100
printf 'lab_directory %s\n' "$lab"

初始余额是一百。备库上的可重复读事务先执行一次查询，再保持打开。脚本核对这个后端确实处于事务内空闲状态并持有快照，随后请求暂停日志回放，并等待实际暂停。主库把余额提交为八十，捕获提交之后的日志位置，作为这次读取需要达到的进度目标。

预期输出分别显示主库余额八十、暂停副本余额一百。五次回放检查之间进行短暂等待，结果都为假，于是输出新鲜读取门槛等待失败的标记。这表示必要变更尚未应用，不能确认读取足够新。实验不会悄悄接受旧结果，也不把这些轮询间隔解释成精确的端到端延迟保证，因为每次连接与查询本身同样需要时间。

回放恢复之后，脚本等待其位置达到目标，然后新建的备库查询必须读到八十。原有可重复读会话此时再次查询，却仍然看到一百。保存的会话输出必须连续包含两次一百，证明旧快照在回放进度变化之后仍然有效。因此，“服务端已经追上”和“这个事务仍然读取旧数据”可以同时成立，不能把它们误诊成相互矛盾的统计。

脚本提交保留的读事务，关闭管道，停止两个实验服务，并打印日志目录。断言检查真实数据库值和实际回放状态，不依赖应用缓存推测。这次演练不会修改任何生产路由或连接池；其完成条件是把不同读取边界分别观察清楚，而不是宣称已经完成业务系统的副本路由改造。

明确路由所承诺的结果

进度标识必须属于目标副本所在的同一条数据库历史。日志位置不是在无关集群或已经分叉的时间线之间全局唯一的业务版本。生产环境中的进度门槛需要绑定相关拓扑，并明确处理故障切换。这个夹具使用固定主库及其直接副本，所以身份关系由建立实验的过程保证，不能把这一前提从生产方案里省略。

如果请求预算内无法确认新鲜度，应明确返回应用能够解释的状态，或在已授权且容量允许时从写入节点读取。不能因为达到截止时间，就暗中降低结果含义。门槛满足后再取得新快照，并保持事务足够短，避免旧快照长期保留使后续进度检查失去意义。业务需要的是确定的读取契约，而不只是尽量快地返回一个数字。

备库上的长查询还可能与恢复工作冲突。PostgreSQL 可以取消它们以推进回放；反馈设置则会在减少取消与增加主库旧版本保留之间交换代价。应联合观察回放延迟、查询取消与事务年龄。评估副本收益时，也要测量真正从写入节点移走了多少读取工作，并把复制开销及维护副本的运行成本一起纳入判断。

来源

PostgreSQL 18 热备，只读恢复、事务快照与恢复冲突，已核验 2026-09-12。
PostgreSQL 18 管理函数，回放位置及暂停、继续语义，已核验 2026-09-10。
PostgreSQL 18 复制配置，备库延迟与反馈的代价交换，已核验 2026-09-12。

停滞的复制槽会继续保留 WAL

Mon, 19 Oct 2026 00:00:00 +0000

PostgreSQL 复制槽记录某个消费者需要保留的材料。一旦槽已经预留日志位置，消费者连接消失，并不会自动解除这份要求。主库可能继续生成日志，而槽的保留起点一直不动。实际风险是磁盘保留量增长，以及追赶还是重建越来越难取舍。槽是否可用，取决于必需日志是否仍然存在，以及实际配置的失效规则。

坏掉的样子

新建物理复制槽不一定立即保留 WAL。如果没有请求立即预留，在槽第一次使用之前，重启位置可能始终为空。因此，仅凭不活跃标志不能量化保留量。需要结合槽类型、预留位置、可用状态和消费者归属来理解。对于逻辑槽，已确认刷新位置描述消费者确认的进度，也不能替代对更早重启位置及其保留义务的分析。

删除槽解除的是这个槽的要求，不一定会在同一瞬间删除文件。检查点清理和其他保留条件仍然有效。别的复制槽、归档积压或日志预留，都可能继续保留文件；回收还可能只是重命名供将来复用，并不把全部已分配字节交还文件系统。多个消费者需要的日志区间可以重叠，所以把每个槽的滞后量简单相加也会重复计算。

保留限制是在两种风险之间做交换。槽的最大日志保留量在检查点附近执行，不是瞬间限制磁盘大小的硬配额。落后足够多的槽可能失去必需日志并变得不可用。这样减少无限保留风险，代价是放弃该消费者现有的追赶路径。仅仅静默时间长，不足以证明可以删除一个仍有真实消费者依赖的槽。

快速验证

在 Linux shell 环境里，以非超级操作系统账户运行脚本，准备 PostgreSQL 18 服务端和客户端程序。本次实际执行版本是 PostgreSQL 18.6。私有临时集群不打开 TCP 监听，客户端通过私有 Unix 套接字连接，里面只有实验用复制槽。少量有日志写入配合强制切段，使保留现象快速可见；这不是对真实业务日志生成量的性能基准。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-slots.XXXXXX)
mkdir "$lab/socket"
cluster=$lab/data
cleanup() {
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
}
trap cleanup EXIT
initdb -D "$cluster" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$cluster/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_replication_slots = 4
max_slot_wal_keep_size = -1
min_wal_size = '32MB'
max_wal_size = '64MB'
checkpoint_timeout = '1h'
CONF
pg_ctl -D "$cluster" -l "$lab/server.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('unused_slot');
SELECT active,restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot';
DO $$ BEGIN
 IF (SELECT restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'unexpected immediate reservation';
 END IF;
END $$;
SELECT pg_drop_replication_slot('unused_slot');
CREATE TABLE churn (value text);
SELECT * FROM pg_create_physical_replication_slot('held_slot',true);
SQL
segment=$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_walfile_name(restart_lsn) FROM pg_replication_slots WHERE slot_name='held_slot'")
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT active,wal_status,pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
FROM pg_replication_slots WHERE slot_name='held_slot';
DO $$ BEGIN
 IF (SELECT NOT active AND wal_status='extended'
 AND pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
 FROM pg_replication_slots WHERE slot_name='held_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'inactive slot did not retain the expected WAL range';
 END IF;
END $$;
SQL
test -f "$cluster/pg_wal/$segment"
echo inactive_slot_retains_old_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_drop_replication_slot('held_slot')" >/dev/null
test -f "$cluster/pg_wal/$segment"
echo drop_did_not_immediately_remove_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c CHECKPOINT
test ! -f "$cluster/pg_wal/$segment"
echo checkpoint_released_old_segment_name
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
ALTER SYSTEM SET max_slot_wal_keep_size='32MB';
SELECT pg_reload_conf();
SQL
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT current_setting('max_slot_wal_keep_size')='32MB'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('limited_slot',true);
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT wal_status,invalidation_reason FROM pg_replication_slots WHERE slot_name='limited_slot';
DO $$ BEGIN
 IF (SELECT wal_status='lost' AND invalidation_reason='wal_removed'
 FROM pg_replication_slots WHERE slot_name='limited_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'slot limit did not invalidate the test slot';
 END IF;
END $$;
SELECT pg_drop_replication_slot('limited_slot');
SQL
printf 'lab_directory %s\n' "$lab"

第一个物理槽创建时不立即预留。输出中的假与真，分别表示槽不活跃、重启位置为空。脚本对此作出断言，再删除这个尚未使用的夹具。下一个槽明确请求预留，而且始终没有消费者连接。经过写入、切段和检查点后，观察到不活跃、保留范围超出最大 WAL 目标，以及按日志位置差计算落后超过六十四兆二进制字节的状态。

脚本先检查最初需要的日志段仍然存在，再删除这个测试槽，并确认文件随即仍在。后续检查点之后，旧日志段名字才消失。这些结果把解除保留要求与立即完成文件系统清理区分开来，并不声称整个日志目录一定变空，也不声称原空间被回收后就一定从文件系统占用中消失。

最后一阶段设置三十二兆二进制字节的槽保留限制，核对配置重新加载已经生效，再预留一个新槽。继续写入和切段，使它超过限制。检查点之后，必须得到日志已经丢失、失效原因是必要日志被移除的结果；断言核对可用状态与原因。这里观察到的是槽的恢复路径丢失，不是某个备库成功追赶到了当前位置。

脚本只删除自己的测试槽，退出时停止临时服务，并打印保留日志与数据的目录，便于复核。整个演练不会断开或重建真实消费者。需要清理的是实验专属资源，生产里该不该放弃某条复制链路，仍然要由消费者归属与恢复承诺决定，不能机械照抄测试中的删除动作。

根据归属与可恢复性作决定

监控重启位置、日志状态、安全余量、不活跃时间、实际保留字节以及剩余空间。安全余量为空，可能表示没有设置保留上限，也可能表示槽已经失效，所以必须结合其他字段解释。PostgreSQL 18 还提供明确的失效原因，可以区分日志被移除与其他原因，避免单纯根据静默时长猜测。

退役一个槽之前，要找到它的所有者，并确认消费者是否还会恢复。何时应重新建立副本，何时应继续保留历史，应当明确选择。若必要日志已经消失，事后调大限制并不会重新生成它。只有替代消费者从一致起点建立起来，并且持续向前推进，才能把这次事件视为恢复。单纯看到磁盘曲线下降，不能证明复制服务也恢复了正常。

来源

PostgreSQL 18 复制槽视图，预留位置、可用状态、安全余量与失效原因，已核验 2026-09-12。
PostgreSQL 18 复制配置，在检查点执行的复制槽日志保留限制，已核验 2026-09-12。
PostgreSQL 18 管理函数，物理槽创建、立即预留及删除接口，已核验 2026-09-10。