@i @Lunarised @lunarised

> as it avoids the https://blog.freespeechextremist.com/blog/activities-visibility-index-slowness.html issue when restoring,

Ah, I should update that; putting the connection into replica mode actually speeds it *way* the hell up.

> https://gitlab.com/-/snippets/2228488

Did Gleason seriously try to use nano on a DB dump? "Editing dumps / I have no idea." The JavaScript guy doesn't think to use awk or sed, huge shock. Someone should tell him (or, since he mercifully has gone away to Nostr, someone should maybe upload some better instructions).

> with --rsyncable

I didn't know about this flag, but it appears to be a Debian extension. pbzip2 does fine.

The bigger issue with this person's approach is that you will have to copy every block every time anyway; pg_dump gives you the dump in disk-order, and in a database where there are large tables with any amount of churn (Pleroma, this database), you will get a different order every time you dump, so rsync will not be able to just move the blocks that have changed.

(Postgres does row-versioning and deletes rows in place by marking them as deleted. To keep the data consistent during transactions, if there is an update, rows are COW'd. New rows get put into empty slots where they fit, overwriting previous deletions.)