last_upgrade.log lost on pod restart - even when upgrade fails

• Which image of the operator are you using? e.g. ghcr.io/zalando/postgres-operator:v1.13.0 : ghcr.io/zalando/postgres-operator:v1.12.2
• Where do you run it - cloud or metal? Kubernetes or OpenShift? [AWS K8s | GCP ... | Bare Metal K8s] : k3s on VMs
• Are you running Postgres Operator in production? [yes | no]: yes
• Type of issue? [Bug report, question, feature request, etc.]: feature request

First of all, thanks for this great piece of software that certainly makes life simple for many of us. I would like to request a change based on my recent experience.

When the operator triggers in-place upgrade of postgres, the logs of the upgrade scripts are output on last_upgrade.log, which happens to land on /home/postgres/last_upgrade.log since this is the user usually running this. Since the upgrade is triggered via k8s exec on the pod, the logs are not available for inspection anywhere else. If the upgrade fails and the pod were to restart for any reason, these logs are lost since /home/postgres is part of the pod root filesystem.

It would be ideal to put this log file in the pgdata folder (or in a sub-folder) that is mounted from a PV. It is over-written on next inplace-upgrade and generally very small in size. This way it will persist between restarts.

Ps. I would be happy to propose a fix if required.

Start by locating the in-place PostgreSQL upgrade path and the code that writes /home/postgres/last_upgrade.log. Verify how the pgdata volume is mounted, then make the log persist through pod restarts while remaining overwritten on the next in-place upgrade; cover both successful and failed upgrades.