Thread: 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 w=
hen 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=20

This is version 7.2.3 and the pg_dump used -c -C -o -Fc -Z1 -b switches,  p=
g_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)