From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Philip Warner <pjw(at)rhyme(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in pg_dump/restore -o |
Date: | 2002-01-17 22:27:05 |
Message-ID: | 25535.1011306425@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-01-17 22:35:24 | Re: [PATCHES] guc |
Previous Message | Liam Stewart | 2002-01-17 21:54:34 | guc |