For those that run Element server and run postgresql version older than 13 will need to update their postgresql major version.
I found these instructions by ‘maxkratz’ on their github page which worked perfectly for me to go from 11 to 16.
Hopefully this helps someone!
You must log in or register to comment.
Does anyone know why postgresql is such a pain when it comes to upgrades? Why doesn’t it just do an in-place upgrade of the DB automatically when starting the new version?
That’s the thing I don’t like about Postgres either. The performance is significantly better than with MariaDB but Postgres is such a pain for non-enterprise use.
Same with crash recovery, Postgres just can’t recover if the WAL is corrupted. MariaDB will happily fix itself but Postgres will just sit there and wait until somebody babysits it.
So you better spin up a second Postgres container, run
pg_resetwal, restart the database and terminate any open transactions manually with a 2 page query you hopefully wrote down. Might reindex all tables as well to be sure.I have a separate “postgres unfuck” script by now.
For minor version upgrades, the database remains binary compatible. Nothing to do.
The dump/restore required during major upgrades allows format changes which enable new features and performance improvements without dragging around cruft forever to stay backwards compatible.
For professionals running PostgreSQL clusters in production there is a way to cycle in the new server version with zero user-visible downtime.
It’s just weird that it doesn’t do the dump-restore automatically when it detects data from an old version.
I like PSQL far more than Maria DB, but it is the most stupid software for upgrades. It is the reason that, whenever I can’t use SQLite, I use a NoSQL DB like Mongo - any single executable NoSQL that contains the entire DB to a single directory seems to be the common factor. Sometimes you might hit an API change, but I think the number of times I’ve had a production application break because of a NoSQL DB server software upgrade is still at 0.
I’ve spend more than a decade supporting both Postgres and MongoDB in production.
While they each have quirks, I prefer the quirks of Postgres.
I just spent a massive amount of time retooling code to deal with a MongoDB upgrade. The code upgrade is so complex because that’s where the schema is defined. No wonder MongoDB upgrades are easier— the database has externalized a lot of complexity that now becomes some coders problem to deal with.
MongoDB does have that annoying quirk where it creates several huge files even with a small amount of data in the DB itself. But at least it can be upgraded.
SQLite is really the only one I’ve used that doesn’t bother me in some way.
Agreed, SQLite 💗. It does have limitations when you need to scale with remote connections and concurrency; then you have to start bringing in layers, and it’s really not designed for that. For those jobs, it’s just better IMO to reach to something designed for that use case to begin with.
Fantastic, thanks for this. Any reason you didn’t go to 17?
No particular reason. Just chose one and went with it.
