repmgr 4.1 makes node failures visible to scripts

A command can print a warning that a person understands while returning success to the script that invoked it. In replication management, that mismatch matters. A monitoring wrapper may know only whether its child process succeeded, even when the child has discovered a failed node. repmgr 4.1 changes this behavior for several inspection commands.

The July 31 announcement says that repmgr cluster show, repmgr node check and repmgr node status now return a nonzero exit status when they detect node-status issues. It also makes unrecognized options errors. These changes improve the information available to automation without requiring it to interpret every human-readable output line.

I want database administration commands to expose their findings in a form that a script can use directly. PostgreSQL's operational detail is valuable only when the surrounding tools preserve it. A replication tool that reports an unhealthy node through its process status gives automation a useful signal at the point where it needs to decide what happened.

Status inspection has two kinds of failure

An inspection command can fail to execute, or it can execute and discover an unhealthy system. Those outcomes are conceptually different even when both require attention. A script that sees only a zero status for the second outcome has no direct reason to treat the inspection as unsuccessful. Someone must then add output parsing or another source of state.

The change does not turn an exit code into a complete diagnosis. A nonzero result still needs context before an operator chooses a response. Its value is that the result no longer disappears into a success path. The script can retain the command's output, notify an operator, or stop a dependent procedure while preserving the evidence needed for diagnosis.

Unknown-option handling addresses another ambiguity. If a misspelled option is accepted or ignored, the command that ran may differ from the command its author thought was running. Refusing the invocation prevents a misleadingly successful result. That is particularly useful in scripts whose intended checks are visible only in their arguments.

This is an interface contract between the tool and the process supervising it. Human output can explain the details, but the process status decides which branch many wrappers take. It deserves the same attention as a SQL result that another program consumes. A more accurate status can change existing automation even when the displayed information looks familiar.

Quiet output and structured events

The release adds a quiet option and CSV output for cluster events. These serve different consumers. Quiet mode suppresses non-error output when a caller already has another way to record ordinary progress. CSV gives event consumers a format that does not depend on the spacing of a display intended for a terminal.

Neither change removes the need to understand what the command reports. A machine-readable format describes how values are represented. It does not establish what response an automation system should take to those values. That decision still belongs to the operational policy surrounding the tool.

My preference is for that division to remain explicit. repmgr should report the state it observes and reject invalid requests. A supervising script can then implement a bounded policy based on those results. Inferring a failover decision from an incidental phrase in terminal output makes the relationship harder to inspect.

Daemon behavior changes at the process boundary

The 4.1.0 release notes also change repmgrd's defaults. It now creates a PID file and daemonizes by default, with --daemonize=false available when needed. Those are process-management details, but they affect which process a supervisor believes it started and how it identifies that process later.

A daemon's behavior must agree with the service definition that launches it. A supervisor expecting a foreground child interprets process lifetime differently from a launcher expecting a forked background process. The release therefore deserves attention in service configuration as well as database configuration. The supplied option makes the intended process model expressible.

The same notes require an extension update on the primary and a repmgrd restart on every node running it when upgrading from the preceding 4.0 releases. PostgreSQL itself does not require a restart for that path. This distinction lets an operator describe exactly which service changes state during maintenance.

Switchover has an explicit refusal condition

Another release change refuses a standby switchover while an exclusive backup is running on the current primary. That check gives a specific reason for rejecting an administrative request before carrying it through. It is different from detecting that the request's syntax is invalid or that a node is unhealthy.

Such refusal conditions matter because administrative commands operate within other workflows. A switchover request may be valid in isolation while conflicting with an operation already in progress. Reporting that conflict directly gives the operator a clearer explanation than letting the workflows interfere later.

For this release, the practical changes therefore reach several parts of replication automation. Inspection commands expose unhealthy results through exit status, invocation errors become explicit, and daemon startup has new defaults. A script or service definition using repmgr needs to reflect those documented behaviors so that the process it supervises and the result it interprets match its intended operation.