I'm pruning an 8.4 database that was using a *lot* of space in pg_largeobject (400GB according to my size query). What I've done seems to work, but I don't know if there's a time-bomb waiting for me, so I have to ask you who've implemented this part. Steps:
2) On
old.godhelpme.server.com:
pg_dump --verbose -Fc -Z 0 --schema=foo --schema=bar --schema=public mydbname | nc other.better.server 1234
That part's pretty cool, streaming out/in works really well. By specifically picking my schemas, no large objects come across. I've already migrated out to filesystem most of them, there's around 102 actual LO's I still need though, so then:
3) On
old.godhelpme.server.com:
time psql -qAt -d mydbname -c 'copy (select loidcolumnname from thistable where loidcolumnname is not null) to STDOUT' >> myneat.list
I do #3 on a few tables, sort and uniquify the rows, then get the data out by:
Where extract_blobs.sh looks like this:
#/bin/bash
psql -qAt -d mydbname -c "copy (select * from pg_largeobject where loid = ${1}) to STDOUT" >> /Volumes/some-less-bad-disk/the-blobs.copy
I rsync that to the new machine, then:
5) On
new.better.server.com:
cat the-blobs.copy | psql -At -d mydbname -c "copy pg_largeobject (loid, pageno, data) from STDIN"
That seems to work - I spun up the new db, can add new blobs, but I notice that the loid is /lower/ than some of the ones I've imported, so
** MY QUESTION ** - Will pg_largeobject automatically choose new OIDs that don't conflict, if I've added lo's this way, by direct COPY?
Thanks so much for reading this far. If you're in London, Ontario, Canada, let me know and I'll buy you a good beer. (some limitations may apply! :)
./scc