Option to disable WAL archiving on standby clusters while still using pgBackRest repos

[bare-id-technik]

Overview

When configuring a PostgresCluster as a standby of another cluster, the operator currently requires a spec.backups section in order to point the standby at an existing pgBackRest repository. As a side‑effect of defining any backup configuration, the operator sets archive_mode=on and configures the same archive_command (e.g. pgbackrest --stanza=<stanza> archive-push "%p") on all pods in the cluster, including standbys
This causes standby instances to push WAL segments into the repository, which consumes unnecessary disk space and network bandwidth. On large environments the pgbackrest directory on the standby grows several times larger than the one on the primary, even though no backups are taken on the standby.

It would be very useful to have a way to disable archiving from standby clusters while still being able to fetch a base backup and replay WAL from a shared repository.

Use Case

Using a repo-based standby setup as described in the disaster recovery guide will always result in this situation.

Steps to reproduce:

Deploy an active cluster pg-primary with a spec.backups section.
Deploy a standby cluster pg-standby with spec.standby.enabled: true, spec.standby.repoName: repo1 and the same spec.backups configuration (this is required so that the operator knows which repo to fetch from).

On the standby pod, inspect the PostgreSQL configuration:

SHOW archive_mode;      -- returns 'on'
SHOW archive_command;   -- returns `pgbackrest --stanza=<stanza> archive-push "%p"`

After some time, check the filesystem usage on the standby node. The pgbackrest directory is several times larger than on the primary, because the standby is pushing WAL segments to the repository.

There is currently no way to prevent the operator from setting the archive_command on standbys without omitting spec.backups, which in turn makes it impossible for the standby to fetch WAL from the repo.

Desired Behavior

Provide an option in the PostgresCluster CRD to disable archiving on standby clusters (e.g. spec.standby.archiveEnabled: false) while still allowing the standby to use repoName to fetch WAL for recovery.

Alternatively, adjust the operator logic so that when spec.standby.enabled: true, the operator sets archive_command to a harmless command like /bin/true on standby pods by default, similar to how it does when spec.backups is omitted
-> see optional backups.

Along with that the standby could still perform a full backup if explicitly requested via pgbackrest backup and should ensure that primary promotion automatically re‑enables archiving.

Environment

• Platform: Kubernetes
• Platform Version: v1.33.1
• PGO Image Tag: ubi9-5.8.2-0
• Postgres Version17
• Storage: S3 compatible storge
• Number of Postgres clusters: 2

Additional Information

Please provide any additional information that may be helpful.