A compatibility issue with Postgres 12 was discovered, preventing upgrades. Wingtip reported the issue, which occurred when running ./launcher rebuild app due to the script looking for Postgres 13 instead of 12.
Wingtip mentioned that upgrading to Postgres 13 requires too much disk space, which is why they are still using Postgres 12. merefield suggested creating a fresh Discourse instance with Postgres 13, restoring the backup, and remapping the server in DNS. However, Wingtip would like to avoid this process.
Additionally, Falco mentioned that Postgres provides an in-place upgrade option using the --link flag, which can be used to save disk space during the process. Wingtip suggested documenting this option to help others facing similar issues.
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.
