Gabriele Bartolini

> still an issue - or rather, we had to delete and re-deploy and restore data... but certainly still a problem that a simple but rare case of disk full...

This is missing. Consider that at the moment our "replica cluster" story is not yet complete. In this specific case, we should monitor if the WAL receiver is up. Our...

I checked and we already monitor this: https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-WAL-RECEIVER-VIEW Look at the `pg_replication` metric in the Prometheus exporter. See: https://github.com/cloudnative-pg/cloudnative-pg/blob/main/config/manager/default-monitoring.yaml#L109

> We like to see an option where none of the bootstrap options (initdb/pg_basebackup/recovery) What does that even mean?

Oh ... I get it now. We cannot skip `initdb` as that's required by Postgres to create a cluster. You simply want, as part of the initdb bootstrap, to avoid...

Just to be clear, you'd like to make the line disappear if, after a failure, things are now working correctly (i.e. failed timestamp < success timestamp). Am I right?

Please look at #1402

Why are you trying to manually run (with errors) `SELECT * FROM pg_backup_stop\nSELECT * FROM pg_backup_stop;` and `SELECT * FROM pg_backup_stop;`?

In my experience, not everyone would like to always reset the last time of failure of the archiver. Postgres allows you to do it, and you can do it, as...

> I (no-one) didn't run the command `SELECT * FROM pg_backup_stop`. And now, I have issue with all my DBs - Last Failed WAL and with same data - 2024-03-01...