Breaking Changes to latest Element server
from talentedkiwi@sh.itjust.works to selfhosted@lemmy.world on 22 Jan 18:15
https://sh.itjust.works/post/31512725

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!

#selfhosted

threaded - newest

limitedduck@awful.systems on 22 Jan 19:51 next collapse

Fantastic, thanks for this. Any reason you didn’t go to 17?

talentedkiwi@sh.itjust.works on 22 Jan 20:09 collapse

No particular reason. Just chose one and went with it.

MangoPenguin@lemmy.blahaj.zone on 22 Jan 23:12 collapse

Does anyone know why postgresql is so broken when it comes to upgrades? Why it doesn’t do an in-place upgrade of the DB automatically when starting the new version?

I’ve had enough problems with postgresql that I basically avoid anything using it unless I have no other options.

sxan@midwest.social on 22 Jan 23:58 next collapse

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.

MangoPenguin@lemmy.blahaj.zone on 23 Jan 00:08 next collapse

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.

sxan@midwest.social on 23 Jan 01:44 collapse

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.

markstos@lemmy.world on 23 Jan 00:25 collapse

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.

markstos@lemmy.world on 23 Jan 00:20 collapse

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.

MangoPenguin@lemmy.blahaj.zone on 23 Jan 01:36 collapse

It’s just weird that it doesn’t do the dump-restore automatically when it detects data from an old version.