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
