This request comes as an output of this issue: cloudnative-pg/cloudnative-pg#10416
When taking on-demand-backups, a user will not be able to successfully recover from that backup unless:
- Another
INSERT command is run to for a sync of the WAL on a standby replica
- A SUPERUSER calls
SELECT pg_switch_wal(); on the primary replica to force the creation of a new WAL file.
- The
backup.target is set to primary
While probably not an issue for very busy databases, this caught me out on some DBs that have very infrequent usage.
Exposing backup.target is preferable from a security perspective because the user does not need to access and account with the SUPERUSER roll. It also is operationally less complex than creating an automated task to run an INSERT or SELECT pg_switch_wal(); after each backup.
PR here: #847
This request comes as an output of this issue: cloudnative-pg/cloudnative-pg#10416
When taking on-demand-backups, a user will not be able to successfully recover from that backup unless:
INSERTcommand is run to for a sync of the WAL on a standby replicaSELECT pg_switch_wal();on the primary replica to force the creation of a new WAL file.backup.targetis set toprimaryWhile probably not an issue for very busy databases, this caught me out on some DBs that have very infrequent usage.
Exposing
backup.targetis preferable from a security perspective because the user does not need to access and account with theSUPERUSERroll. It also is operationally less complex than creating an automated task to run anINSERTorSELECT pg_switch_wal();after each backup.PR here: #847