postgres:18 (tracked by pgautoupgrade) relocated the default PGDATA from
/var/lib/postgresql/data to /var/lib/postgresql/18/docker. Since the db volume
is mounted at the legacy path, pg18 would init a fresh empty cluster there and
orphan all existing data (pgautoupgrade never runs the upgrade). Pinning PGDATA
to the legacy path makes pg18 find the existing cluster and upgrade it in place.
I see there are some other ways to do the 17->18 pg migration, but I couldn't get any to work cleanly besides setting PGDATA=/var/lib/postgresql/data . Setting this though, the upgrade path is tested and working
Notes:
- I see there are some other ways to do the 17->18 pg migration, but I couldn't get any to work cleanly besides setting `PGDATA=/var/lib/postgresql/data` . Setting this though, the upgrade path is tested and working
cc @3wordchant@simon I know we haven't officially figured out maintainership of this recipe yet, but pinging you as this bump PR contains some CVE fixes (e.g. nginx) so probably good to get it in soon
cc @3wordchant @simon I know we haven't officially figured out maintainership of this recipe yet, but pinging you as this bump PR contains some CVE fixes (e.g. nginx) so probably good to get it in soon
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Notes:
PGDATA=/var/lib/postgresql/data. Setting this though, the upgrade path is tested and workingcc @3wordchant @simon I know we haven't officially figured out maintainership of this recipe yet, but pinging you as this bump PR contains some CVE fixes (e.g. nginx) so probably good to get it in soon
c94186132cto5fc9296e61upgrade-7.3.0+v1.154.0to upgrade-7.2.0+v1.154.0