@ins0mniak@dcc@nyanide@lain@lord_nougat@Sovereign@lain@verita84 Don't fucking bother. You'll be micro-optimizing Postgres for eternity. The slabs have shittier IOPS than my old 80G IDE hard drive and using lvmcache to offset the shitty performance only helps you so much.
@phnt@dcc@ins0mniak@nyanide@lain@lord_nougat@lain@verita84 Oh ok! Thank you! I'll check into learning how to make those hehehe. Well I guess having a VM snapshot is my way of doing that without directly doing that. Ill try to upgrading directly from 2.8.0. I assume #hashtags work and a few new features came out?
= Pleroma =
== Database backup ==
=== schema ===
sudo -Hu postgres pg_dump -s pleroma -S postgres -v -f /mnt/pleroma-schema.psql
=== data (one or the other) ===
sudo -Hu postgres pg_dump -a pleroma --disable-triggers -S postgres -v -f /mnt/pleroma-data.psql # Uncompressed only
pg_dump -a pleroma --disable-triggers -S postgres -v -f - | nice bzip2 -z9 - >/mnt/pleroma-data.psql.bz2 # Run as postgres user
== Database restore ==
=== schema ===
psql -v ON_ERROR_STOP=1 -d pleroma -U postgres -a -f pleroma-schema.psql
=== data ===
psql -v ON_ERROR_STOP=1 -d pleroma -U postgres -a -f pleroma-data.psql
Backing up the DB with the custom format pg_dump -Fc might lead to a really long restore time thanks to indexes being built in a bad way. There's probably a way to workaround that and still use the custom format, but I've never tried to find one.
You can now in 2.9.0 follow hashtags, but it isn't exposed in Pleroma-FE anyway. Husky/Tusky might have that functionality, but I never found the need for it. If you are going from 2.8.0 to 2.9.X, there are migrations you will need to run (check 2.9.0 release article on the main site).
1. Stop Pleroma (just to be sure) 1.5 Backup DB 2. MIX_ENV=prod mix deps.clean mime --build (this one is not in the notes, but Pleroma yells for not doing it for this specific release) 3. MIX_ENV=prod mix deps.get 4. MIX_ENV=prod mix compile 5. MIX_ENV=prod mix ecto.migrate 6. Start Pleroma
I would switch to the stable branch with git switch stable instead and run git pull origin stable after that. That should give you the newest release. From there run the normal upgrade commands I've sent above.
1. cd /opt/pleroma 2. git switch stable (you probably are on that branch, if you followed one of the install guides) 3. git pull origin stable (a bunch of output for every changed file should spew out)
>Also, do you know what would cause this in the server logs? It is probably a easy settings fix in the Admin FE.
Never saw anything like that and considering the all caps ERROR I don't even think that is coming from Pleroma.
In this backup DB case, the official docs just say, run pg_dump -Fc ... and restore the schema and data at once.
Gleason made a GitLab snippet which avoids the annoying long index build problem, but at the same time, the commands he gives you actually don't work, because the disabled triggers at data import need database superuser (postgres) privileges and he runs the restore as the normal pleroma user.
And Pete wrote a blog post about the annoying index and how to actually work around it at the bottom of the article. And that should work with the custom format, but I've never tried it, so use at your own risk.
Guys, thanks so much for the help. Sadly the upgrade did not go smoothly. At first I ran all the listed commands and when I checked the version, it never upgraded lol. I used ChatGPT, told it what happened, and it was somehow able to get me squared away. I am pretty sure I'm on the newest version now.
It is, but it will probably break if you move it to a system with a different collation and collation version (a reindex might fix that). And it will definitely break if you move it to a system with a different postgres version. But if you have two systems with identical setups, this is definitely an option.