Egregoros

holy shit just finish already

@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

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

@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)

@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