Deploy the PostgreSQL K8s charm with the application name equal to postgresql-k8s.
Deploy the S3 integrator charm, configure it and relate it to the postgresql-k8s application.
Create a backup, then write some data and later create another backup.
Remove the postgresql-k8s application.
Deploy a new PostgreSQL charm with the application name equal to db.
Relate it to the S3 integrator application and trigger a PITR with juju run db/leader restore restore-to-time="latest" --wait=1000s.
Expected behavior
Restore is successfully completed, and the unit has a status equal to Move restored cluster to another S3 bucket.
Actual behavior
Restore fails, and the unit has a status equal to cannot restore PITR, juju debug-log for details.
Versions
Operating system: Ubuntu 24.04 LTS
Juju CLI: 3.4.5-genericlinux-amd64
Juju agent: 3.4.5
Charm revision: 337
microk8s: v1.29.5 revision 6884
Log output
Juju debug log:
unit-db-0: 23:34:35 ERROR unit.db/0.juju-log Restore failed: database service failed to reach point-in-time-recovery target. You can launch another restore with different parameters
unit-db-0: 23:34:35 ERROR unit.db/0.juju-log Can't tell last completed transaction time
Additional context
The issue happens because the stanza name contains the name postgresql (from the previous PostgreSQL charm deployment), and the new application is using its application name (db) to search for a stanza from which it can perform the PITR.
github-actions[bot]
commented
1 month ago
Steps to reproduce
postgresql-k8s.postgresql-k8sapplication.postgresql-k8sapplication.db.juju run db/leader restore restore-to-time="latest" --wait=1000s.Expected behavior
Restore is successfully completed, and the unit has a status equal to
Move restored cluster to another S3 bucket.Actual behavior
Restore fails, and the unit has a status equal to
cannot restore PITR, juju debug-log for details.Versions
Operating system: Ubuntu 24.04 LTS
Juju CLI: 3.4.5-genericlinux-amd64
Juju agent: 3.4.5
Charm revision: 337
microk8s: v1.29.5 revision 6884
Log output
Juju debug log:
Additional context
The issue happens because the stanza name contains the name
postgresql(from the previous PostgreSQL charm deployment), and the new application is using its application name (db) to search for a stanza from which it can perform the PITR.Copied from VM issue: https://github.com/canonical/postgresql-operator/issues/562.