Re: Bug in pg_dump/restore -o

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bug in pg_dump/restore -o
Дата
Msg-id 25535.1011306425@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Bug in pg_dump/restore -o  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tuptoaster.c must *not* use SnapshotAny
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCHES] guc