Replication · XB Field Notes

Postgres streaming replication keeps a warm standby

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

Physical streaming replication sends PostgreSQL WAL to a standby, which replays the records to maintain another copy of the cluster. It can send records without waiting for a whole segment to finish. This is distinct from logical replication of selected table changes. A running receiver and a reachable standby are useful health signals, but neither establishes that a particular committed row is already visible there.

When it breaks

Streaming replication is asynchronous by default. The primary can acknowledge a commit before the standby has received or applied it. Losing the primary at that point can lose recently acknowledged work during failover. A connected standby can also receive WAL while replay is paused, leaving reads stale even though network delivery is making progress.

Keep the progress markers separate. On the standby, pg_last_wal_receive_lsn() reports the location received and synchronized to disk through streaming. pg_last_wal_replay_lsn() reports the applied location. Their difference can expose replay backlog. A timestamp for the last replayed transaction ages on an idle system too; elapsed wall-clock time alone is not a reliable measure of missing work.

Check it quickly

Use a non-root Linux account with PostgreSQL 18 server and client binaries in PATH; this script was executed on PostgreSQL 18.6. It creates private temporary clusters and a Unix socket directory with no TCP listener. Local trust authentication is confined to these disposable fixtures. The small WAL reserve supports this bounded exercise; the script does not configure a permanent replication slot.

#!/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"

The script takes a physical base backup with -R, which writes standby connection settings and creates standby.signal. It starts that copy on a different socket port, requests a replay pause, and waits until the actual state is paused. Then the primary commits row two. A captured post-commit LSN provides a concrete target against which to compare receipt and replay.

Expected primary status is streaming|async. On the standby, t|t|1 means receipt has reached the target, replay has not, and the table still contains only the original row. The assertion also checks that row’s value. stale_read_while_receiving therefore records an actual stale query result while log delivery continues, not a simulated delay in an application cache.

After replay resumes, the script waits for the replay LSN to reach the target and verifies 1|base plus 2|later. Each observation uses a new connection, so a previously opened transaction snapshot cannot explain the earlier stale result. Existing long-lived snapshots in applications may still need to end before those applications see freshly replayed changes.

For the takeover step, the script stops the old primary first, then promotes the standby and waits for completion. pg_is_in_recovery() becomes false, and inserting row three produces 3|promoted. Assertions verify that the new primary accepts the write. All experimental servers stop on exit, while the printed directory retains their logs. This tests an orderly, isolated promotion; it does not test automatic failure detection, network partition handling, or client endpoint migration.

Choose the acknowledgment and retention contract

Synchronous replication needs both a configured selection of synchronous standbys and the relevant synchronous_commit setting. Setting that transaction option to on without selected synchronous standbys does not invent a remote acknowledgment requirement. With synchronous standbys selected, on waits for their durable WAL receipt; remote_write waits for writing into their operating systems; remote_apply waits for replay. These choices change latency and availability as well as durability or read visibility.

Retention is another separate obligation. A replication slot can retain WAL needed by a disconnected receiver, but a stalled consumer can exhaust storage unless limits and monitoring are deliberate. Without sufficient retained or archived WAL, an old standby can require rebuilding. Monitor generation, receive and replay progress, retained bytes, and free space together.

Promotion does not fence a competing primary by itself. A real failover procedure must prevent the old writer from continuing, select an acceptable recovery position, redirect clients, and rejoin the former primary through a supported rebuild or rewind process. A healthy streaming connection proves only one part of that procedure.

Sources

PostgreSQL 18 warm standby and streaming replication, asynchronous delivery, synchronous acknowledgments, retention, and failover, checked 2026-09-10.
PostgreSQL 18 administrative functions, receive and replay LSNs, actual pause state, and promotion semantics, checked 2026-09-10.
PostgreSQL 18 pg_basebackup, creating a standby with the recovery-configuration option, checked 2026-09-10.

Read replicas serve demand copies

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

A read replica can serve queries while another database handles writes. That can move reporting, search, or other eligible reads away from the writer, but routing a connection is only part of the design. The application must specify which committed changes a result needs to include. This article uses a PostgreSQL physical hot standby, whose normal recovery mode permits reads but does not accept ordinary writes.

When it breaks

With asynchronous replication, a successful write can be followed by a stale replica read. A user changes an account and refreshes the page, yet the previous value reappears. The replica may be healthy and continuously receiving WAL; the required commit still has to be replayed. A freshness check based on receipt rather than replay tests the wrong boundary.

Even replay progress is insufficient when the query uses an older transaction snapshot. A repeatable-read transaction intentionally preserves its view as recovery advances. Waiting until a replica has applied a write does not refresh that transaction. A correct read-after-write path needs both adequate replay progress and a snapshot taken after the progress condition was satisfied.

The freshness promise must also be limited. Including this user’s earlier write does not guarantee that no newer transaction exists elsewhere. A balance used to authorize another debit still needs a transactional check on the write path. Replica read capacity does not replace the concurrency control that protects the business operation.

Check it quickly

Run this script as a non-root Linux account with PostgreSQL 18 server and client binaries in PATH. The recorded run used PostgreSQL 18.6. It builds private primary and standby clusters connected through Unix sockets, with no TCP listener. A named pipe keeps one reader session open so the snapshot boundary is controlled without installing a driver.

#!/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"

The fixture begins with a balance of one hundred. On the standby, a repeatable-read transaction performs an initial query and remains open. The script confirms its backend is idle inside a transaction with a snapshot, then pauses actual WAL replay. The primary commits a change to eighty and captures a post-commit WAL position as the read’s progress target.

Expected output shows primary_balance 80 and paused_replica_balance 100. Five replay checks separated by short waits remain false, producing fresh_read_gate_timed_out. That result refuses to certify freshness while the required change is unapplied. The exercise does not silently treat the stale result as acceptable or pretend those polling intervals form a precise end-to-end latency guarantee.

Replay then resumes. After its LSN reaches the target, a new standby query must read eighty. The original repeatable-read session queries again and still reads one hundred. Its saved output must contain one hundred twice, proving the old snapshot survived the change in replay progress. Both facts can hold simultaneously: the server has caught up, and that particular transaction still sees older data.

The script commits the held read transaction, closes its pipe, stops both servers, and prints the retained log directory. Its assertions inspect database values and actual replay state. No production routing or application connection pool is changed.

Make the routing promise explicit

A progress token must refer to the same database history as the destination replica. An LSN is not a globally unique business version across unrelated clusters or diverged timelines. Bind any production gating design to the relevant topology and handle failover explicitly. The fixture uses one fixed primary and its direct standby, so that identity is established by construction.

If freshness cannot be established within the request budget, choose an explicit application response or an authorized read from the writer with capacity available. Do not let a deadline quietly weaken the meaning of the result. Acquire a fresh snapshot after the gate succeeds, and keep transactions short enough that snapshot retention does not defeat later checks.

Long standby queries can also conflict with recovery. PostgreSQL may cancel them to let replay proceed; feedback settings trade such cancellations against retention pressure on the primary. Monitor replay delay, query cancellations, and transaction age together. Measure the read workload actually moved off the writer, alongside the replication and operational costs of maintaining the copy.

Sources

PostgreSQL 18 hot standby, read-only recovery, transaction snapshots, and recovery conflicts, checked 2026-09-12.
PostgreSQL 18 administrative functions, replay position and pause/resume semantics, checked 2026-09-10.
PostgreSQL 18 replication configuration, standby delay and feedback tradeoffs, checked 2026-09-12.

A stale replication slot holds WAL back

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

A PostgreSQL replication slot records retention requirements for a consumer. Once the slot has reserved a WAL position, losing the consumer’s connection does not automatically release that position. The primary may keep generating log while the slot’s requirement remains unchanged. The operational risk is retained storage and an increasingly expensive catch-up or rebuild decision. Slot usability depends on retained WAL availability and the configured invalidation rules.

When it breaks

Not every newly created physical slot immediately holds WAL. Without immediate reservation, restart_lsn can remain null until the slot is first used. An inactive flag alone therefore does not quantify retention. Inspect the slot type, reserved position, availability status, and consumer ownership together. For logical slots, confirmed_flush_lsn describes acknowledged consumer progress; it is not a replacement for understanding the older restart_lsn retention requirement.

Dropping a slot removes that slot’s claim, not necessarily the files at that instant. Checkpoint cleanup and other retention requirements still matter. Other slots, archive backlog, or a WAL reserve can keep files present, and recycling may rename them without returning all allocated bytes to the filesystem. Adding every slot’s lag also overcounts overlapping WAL ranges shared by several consumers.

Retention limits exchange one risk for another. max_slot_wal_keep_size is enforced around checkpoints, not as an instantaneous hard disk quota. A sufficiently lagging slot can lose required WAL and become unusable. That protects against indefinite retention at the cost of abandoning that consumer’s existing catch-up path. Age alone is not authority to discard a live replication dependency.

Check it quickly

Run this script as a non-root account with PostgreSQL 18 server and client binaries in a Linux shell environment. It was executed on PostgreSQL 18.6. The private temporary cluster has no TCP listener and contains only test slots. Small logged inserts and forced segment switches make retention visible quickly; this is not a benchmark of business WAL volume.

#!/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"

The first physical slot is created without immediate reservation. Its f|t output means inactive with a null restart position. The script asserts that condition and removes this unused fixture. The next slot explicitly reserves WAL and never connects a consumer. After writes, segment switches, and a checkpoint, the observed state is f|extended|t: inactive, retaining beyond the configured maximum WAL target, and more than sixty-four mebibytes behind by LSN distance.

The script checks the original required segment still exists, drops that one test slot, and checks the file remains immediately afterward. A subsequent checkpoint removes the old segment name. Those observations distinguish releasing a claim from immediate filesystem cleanup. They do not claim the complete WAL directory becomes empty or that recycled storage necessarily disappears.

The final phase sets a thirty-two-mebibyte slot retention limit, confirms the reload took effect, and reserves a new slot. More logged work and segment switches push it beyond the limit. After checkpointing, the required result is lost|wal_removed; an assertion checks both availability state and invalidation reason. This is an observed loss of the slot’s recovery path, not successful catch-up by a replica.

Only fixture slots are dropped. The temporary server stops on exit, and the printed directory retains its logs and data for review. No real consumer is disconnected or rebuilt.

Decide from ownership and recoverability

Monitor restart_lsn, wal_status, safe_wal_size, inactivity, actual retained bytes, and free space. A null safety margin can mean unlimited retention or an already lost slot, so interpret it with the other fields. PostgreSQL 18 also exposes an invalidation reason, which distinguishes removed WAL from other causes instead of guessing from elapsed silence.

Before retiring a slot, identify its owner and whether that consumer is expected to resume. Decide explicitly when rebuilding is preferable to retaining more history. If a required segment is already gone, increasing the limit does not recreate it. Verify the replacement consumer’s consistent starting point and ongoing progress before considering the incident resolved. A smaller disk graph alone does not prove replication service has recovered.

Sources

PostgreSQL 18 replication slots view, reserved positions, availability states, safety margins, and invalidation reasons, checked 2026-09-12.
PostgreSQL 18 replication configuration, checkpoint-enforced slot retention limits, checked 2026-09-12.
PostgreSQL 18 administrative functions, physical slot creation, immediate reservation, and dropping slots, checked 2026-09-10.