> Juan - if you look back in the posts to 4/21, you'll see a thread titled
> "[ADMIN] trouble migrating large objects from 7.1.3 to 7.3.2". In there,
> you'll see I was having a similar problem. I discovered that using the -o
> option of pg_dump was causing the tar archiver error. As it turns out,
> most people don't need the -o option.
>
> If you can, I'd try re-running pg_dump & pg_restore without the -o option.
> If you can't rerun pg_dump or you really need the -o option for pg_dump,
> then I'm not sure how to proceed. I couldn't get it to work either, but
> luckily I didn't need it.
First, thanks to everybody who tried to help me in this trouble.
After thinking a long time, I have found one solution. This solution has steps
that are individuals for each database, but are very simple. I remember that
I use the version 7.3.0, I think that in 7.3.2, some steps could be jumped.
Here is, how to restore a database dump, in Postgres 7.3, that uses the "lo"
type of the contrib dir. I explain the steps of this "algorithm" for
everybody who have the same problem as me.
MAKING THE BACKUP
-----------------------------------
1. We have the dump in a tar file, made with something similar to:
pg_dump -Ft -o -b -U myuser mydb > backup.tar
THE RESTORING PROCESS
--------------------------------------------
2. We drop de database, if it exists.
dropdb -U myuser mydb
3. We restore the structure of the database and create it. Use something
similiar to:
pg_restore -Ft -v -s -C -U myuser -d test backup.tar
4. We access with "psql" to the database and create a implicit cast of the
types "lo" and "oid" on both directions.
5. We delete the triggers in the tables with "lo" columns, that calls the
function "lo_manage".
6.- We restore the data of the database.
pg_restore -Ft -v -a -U myuser -d mydb backup.tar
7.- We create the triggers (again) deleted, in the step 5.
I said that this "algorithm" depends on the particular database that we used,
because the steps (5 and 7).
I think that these steps (5 and 7) could be converted to an database
sistematic database independient step. Therefore if someone can improve this
solution, write to me and we'll speak.
Bye.
Juan Miguel Moreno Escar
juanmime@ono.com
