pg_dump/pg_restore
Hi,
2 possible bugs in pg_dump/pg_restore related to large objects.
1. Large objects dumped, deleted then restored do not retain their original OIDs. Big problem as we reference their OIDs in tables.
2. The pg_restore command --list indicated no Blobs in the dump file even when there are. For example:
.
.
72; 46588445 TABLE DATA table_3da6183d8bb21 nobody
73; 46588481 TABLE DATA table_3da625d622b72 nobody
74; 46588517 TABLE DATA table_3da625f19cc95 nobody
75; 0 BLOBS BLOBS
This is version 7.2.3 and the pg_dump used -c -C -o -Fc -Z1 -b switches, pg_restore used no switches (other than -d, of course).
Thanks,
Colin
---------------------------------------------
Colin Stearman
President
Ashdown Technologies
119 E. Main St.
Milford, MA 01757 USA
Tel: +1 508-478-1234
Fax: +1 508-478-1244
www.ashdowntech.com
"Colin Stearman" <cstearman@infofind.com> writes:
1. Large objects dumped, deleted then restored do not retain their original=
OIDs. Big problem as we reference their OIDs in tables.
They're not supposed to (indeed cannot). pg_restore is supposed to arrange
for references to large-object OIDs to be updated to the new values,
however. I believe it looks in columns of types OID and LO --- if you
stored your references in plain int columns, that was a mistake.
If you're using the -o option simply because you think you need it for
blobs, you don't need it.
2. The pg_restore command --list indicated no Blobs in the dump file even w=
hen there are. For example:
75; 0 BLOBS BLOBS=20
Looks like you have blobs to me: that entry wouldn't even be there,
otherwise.
regards, tom lane
Tom,
You are 100% right about pg_restore fixing up OID references in tables to
blobs (and presumably any other objects). I should have checked more
carefully and given the program more credit.
I will remove the -o as it is not necessary, as you say.
That resolves my script problem Thanks!.
Regarding the --list output, the line reads "75; 0 BLOBS BLOBS", and listing
any database, whether or not it contains blobs, outputs the same thing (the
=20 is an email coding for EOL). So I maintain that it may be a (benign)
bug.
Colin
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Colin Stearman" <cstearman@infofind.com>
Cc: <pgsql-bugs@postgresql.org>
Sent: Sunday, November 24, 2002 12:57 PM
Subject: Re: [BUGS] pg_dump/pg_restore
"Colin Stearman" <cstearman@infofind.com> writes:
1. Large objects dumped, deleted then restored do not retain their
original=
OIDs. Big problem as we reference their OIDs in tables.
They're not supposed to (indeed cannot). pg_restore is supposed to arrange
for references to large-object OIDs to be updated to the new values,
however. I believe it looks in columns of types OID and LO --- if you
stored your references in plain int columns, that was a mistake.
If you're using the -o option simply because you think you need it for
blobs, you don't need it.
2. The pg_restore command --list indicated no Blobs in the dump file even
w=
hen there are. For example:
75; 0 BLOBS BLOBS=20
Looks like you have blobs to me: that entry wouldn't even be there,
otherwise.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)