We’re running postgres v12 as the v13 upgrade requires too much disk space. It looks like compatibility with v12 may have been broken? Is this deliberate? If so it means we can never upgrade Discourse again.
Running ./launcher start app got us back online so it isn’t a production issue right now, but being unable to upgrade even for security issues etc would be very bad news for us.
From app.yml:
- "templates/postgres.12.template.yml"
Running ./launcher rebuild app:
FAILED
--------------------
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/13/main/pg_hba.conf
Location of failure: /pups/lib/pups/replace_command.rb:8:in `read'
replace failed with the params {"filename"=>"/etc/postgresql/13/main/pg_hba.conf", "from"=>"/^host.*all.*all.*::1\\/128.*$/", "to"=>"host all all ::/0 md5"}
0ba8112e6efa1ac2dd75af8a1da8eea0937e7aefbca2df28b22d27e9608d1479
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
It’s less scary than annoying work I’d like to avoid, combined with telling my forum they’re going to lose a day or two of posts. Would like the Discourse guys to say “Of course we still work on PG12, that’s just a bug, we’ll get that fixed up” ideally.
That said, we don’t run PG12 anymore, so we may introduce some SQL syntax exclusive to PG13+ anytime in core, so it would be a good idea to schedule the upgrade someday.
pg_upgrade provides a single --link flag to allow for in-place upgrades.
We opted to not use it in our “newbie-friendly” launcher upgrade script as 99% of installs are running in a cloud VM that can easily and cheaply extend the disk size.
But it’s there as an option for people who prefer to do the upgrade manually in order to save disk space during the process.
There were 2 solutions provided; as I recall one basically needed triple the size of the entire DB and the other needed like double. If it can be done in-place, documenting that would be very useful.
