Re: Bug in pg_dump/restore -o

Philip Warner wrote:
> At 17:27 17/01/02 -0500, Tom Lane wrote:
> >
> >Philip, you're probably the best-qualified to fix this, but if you don't
> >have time today then I can work on it.  I don't want to delay RC1 for
> >this...
> >
> 
> I'm around now; do you still want me to look into this?

Yep.  :-)

> >A potentially more serious problem is that if the archiving code chooses
> >to issue other operations between the schema restore and data restore
> >for the temp table, we might do a \connect and lose the temp table.
> >Come to think of it, a data-only restore request won't work either.
> 
> This leads me to the question: when should the OID restoration be performed
> - in the SCHEMA or DATA phase? ISTM that it is part of the data, and should
> be performed after data restoration. But perhaps I misunderstand what it is
> for.

I believe it should be performed only as part of a data dump.  Saving
the oid during as part of the schema makes no sense because the schema
dump doesn't have any reference to oid's.

> >Philip, is this a fundamental problem, or do we just need to make
> >the tar archiver a little smarter about looking at the COPY strings?
> 
> I need to look into this; there should be no difference.

OK.

> >pg_dump: [tar archiver] bad COPY statement - could not find "copy" in
> string "cr
> >eate temporary table pgdump_oid (dummy int4);
> >copy pgdump_oid with oids from stdin;
> 
> I'm not sure, from your patch code, how it got the CREATE and COPY
> statements in the one string - did you by any chance use an defective dump
> file from a previous patch attempt? 

Well, the problem is that the -Fc format has the CREATE/COPY in the dump
file, but the COPY data is non-compressed, e.g. 12323<tab>0.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026