Re: Bug in pg_dump/restore -o - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug in pg_dump/restore -o
Date
Msg-id 25535.1011306425@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug in pg_dump/restore -o  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Bug in pg_dump/restore -o  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Bug in pg_dump/restore -o  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I think I see the cause.  I created a simple table and then generated
> the dump.  I found this that the normal table had its COPY data in
> binary format while the max oid dump was pure ASCII.  My guess is that
> the max oid dump code isn't calling the right routine to dump its data.

Indeed, the max oid dump code doesn't look like it's been clued at all
about interoperating with the new pg_dump output code.  It can't just
intermix commands and data into one string and expect pg_restore to cope.
Compare what happens in dumpClasses/dumpClasses_nodumpData to what's
being done in setMaxOid.

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...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: tuptoaster.c must *not* use SnapshotAny
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCHES] guc