PostgreSQL 18: the replication error is fixed—why is the subscription still off?

Correcting the original database error does not necessarily restore a logical replication subscription automatically. An important qualification comes first: PostgreSQL 18’s disable_on_error setting defaults to false. This article concerns a subscription configured to disable itself upon worker errors; it does not claim all replication failures behave the same way.

This is a documentation-backed diagnostic guide, not an incident report, test result or demonstration on a real customer’s database.

First separate the error from the subscription state

The official CREATE SUBSCRIPTION documentation states that when disable_on_error = true, a subscription can be automatically disabled if its workers detect replication errors. Once that happens, there are two independent questions:

• Was the underlying error actually resolved? Inspect the original source of the replication/apply problem.
• Is the subscription still enabled? Inspect its catalog state rather than assuming recovery happened.

A fixed cause and an enabled subscription are different conditions. We have not measured a replication backlog, lag, timeline or successful recovery in this draft.

Read-only queries for PostgreSQL 18

The pg_subscription catalog documents subenabled and subdisableonerr. The following statements inspect these fields; they do not repair or restart anything.

-- Read-only. Replace example_sub with your verified subscription name.
SELECT subname, subenabled, subdisableonerr
FROM pg_catalog.pg_subscription
WHERE subname = 'example_sub';

To inspect the subscription statistics, if you have the necessary access:

-- Read-only observation of replication-worker statistics.
SELECT subname, pid, received_lsn, latest_end_lsn, latest_end_time
FROM pg_catalog.pg_stat_subscription
WHERE subname = 'example_sub';

No SQL output is shown, because none was executed during this editorial task. Rows or worker PIDs may be absent for multiple reasons; do not turn that observation alone into a root-cause claim. Inspect relevant server logs, roles, configured publications and actual source state.

Security precaution: PostgreSQL documents that pg_subscription.subconninfo can contain sensitive connection credentials, so avoid publishing a wholesale catalog dump or screenshots of connection strings. Query only the fields needed for diagnosis.

Why ‘just enable it’ is not a safe first step

ALTER SUBSCRIPTION ... ENABLE is a state-changing operation that starts a previously disabled subscription’s worker, but executing it here would be inappropriate. In production, determine why the worker stopped, verify data integrity and privileges, assess catch-up and WAL/slot behavior, and agree on a monitored recovery and rollback plan before any approved change.

A practical decision chain: version → configured disable_on_error → subenabled state → worker errors/statistics → effects of restart → separately authorized recovery.

Official sources: CREATE SUBSCRIPTION, pg_subscription, ALTER SUBSCRIPTION.

The read-only catalog queries are illustrative PostgreSQL 18 diagnostics based on the official manual. They have not been executed in an isolated PostgreSQL 18 test environment for this article; do not assume the sample reveals the status of a live database.