Egregoros

does this pertain to a certain server project of recent ?

@pwm it cooms on it's own damn time, repack next time

@i I should have sucked it up, installed gleasonware, repacked, then done the upgrades

@pwm is this the intiial import?

@i I think I'm building 40 gigs of btrees

@bajax upgrade from pg14 to 18. After this I'm gonna prune it, pack it and that'll be the db sorted

@pwm yeah half the db size is indexing, the wonders of two buckets of jsonb, hope it's not spinning on https://blog.freespeechextremist.com/blog/activities-visibility-index-slowness.html either

@i that's exactly what it's stuck on. If it's not finished when I get back up I guess I kill it and think about it again, but we're not exactly doing a dump and restore (we are, as I understand it, but it's being managed by pg_upgradecluster)

@iwetoddid no I am hacking the mainframe but it's taking too long; going to download moar ram

@iwetoddid I spared you the one where he's getting blown

@pwm @i Starting over again might be faster depending on how long it is taking. On my test VPS a restore took something like 3 days instead of ~8 hours. Of course heavily depends on hardware.

@phnt @i I'm actually doing all the heavy lifting on my desktop so there's plenty of horsepower. There's a good chance that when I wake back up in 7 or 8 hours it will be done. If it's not, I'll take the new index approach, stick it in the old database, and redog it

@pwm @i Next time either dump the database as separate schema/data and first import the schema, or do pg_dump with the custom filetype and first restore the schema.

(The Pleroma docs are fixed, but the updates haven't been pushed to the site.)

@phnt @i I forgot that that was effectively what I was doing, when moving from postgres version to postgres version. So. I received a backup of the file structure and didn't think that I should immediately dump a logical dump and work with that instead. For some reason I assumed I would be saving myself if I let postgres handle it for me

@phnt @i cuz yeah, I knew that trick for backups and have employed it before but in my mind I wasn't dealing with backups when I really was

@pwm @i Oh, also --disable-triggers on data import is important. If you are doing plain sql files, that has to be added on backup creation.

@phnt @pwm where's the "i am a burden on everyone" elephant edit, fits here too, psql is good at everything except being good at it

@i @pwm plain sql backups are a bit of an after thought now, but the custom binary format still somehow sometimes refuses to restore on newer postgres versions. Still the elephant is at least better than the dolphin. That's the reality we live in.

those are replicated, he can just rsync and it should pass data integrity checks as it did prior to and after compression

just fyi every week btrfly databases were repacked. you may need to rebuild some of the prod.secret.exs as it was filled out from customer information but you can figure i ouy from second link

https://gitlab.com/tanataro/rebased-omnibus/-/blob/mas...

https://gitlab.com/tanataro/rebased-omnibus/-/blob/mas...

I purposely dumped the config from the database as well, just in case so there may be duplicates in the prod.secret.exs, that was merging the secret.exs with what the database dumped

this was designed to go much smoother, but well, broken network hardware, missing (unanounced) IP ranges