Re: BUG #7590: Data corruption using pg_dump only with -Z parameter

Поиск
Список
Период
Сортировка
От Jan Vodička
Тема Re: BUG #7590: Data corruption using pg_dump only with -Z parameter
Дата
Msg-id CA+8ZZiJsaowxqi5WGN21ST-9PZEV6WrvNnDc9VDmLJvDyec=rA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #7590: Data corruption using pg_dump only with -Z parameter  (Craig Ringer <ringerc@ringerc.id.au>)
Список pgsql-bugs
That would be definitely much more comfortable solution.
Problem was really in newlines \n vs. \r\n. Replace \r\n -> \n solved problem.

Thanks a lot.


2012/10/13 Craig Ringer <ringerc@ringerc.id.au>
On 10/10/2012 03:07 AM, Jan Vodička wrote:
= not able to unpack, invalid

Try this one generated by "pg_dump -Z1 > backup.gz" in windows:
http://mstu.cz/~hrtlik/backup.gz
<http://mstu.cz/%7Ehrtlik/backup.gz> (0.5kB)
original "pg_dump > backup.gz" without compression:
http://mstu.cz/~hrtlik/backup.sql <http://mstu.cz/%7Ehrtlik/backup.sql>

If you have any way how to get original, tell me.

If Tom is right and the issue is end-of-line transformation, in theory you might be able to un-mungle newlines. The chances of \r\n occurring naturally in a tiny backup like that are not huge, so any \r\n in the data probably used to be a raw \n. Taking a copy of the DB and performing that substitution might get you a usable backup file.

That's replacing all \x0d\x0a sequences with \x0a. Or I might be wrong and it's \x0d.

This won't work on a larger backup where some \r\n sequences will occur naturally in compressed binary data. In those you're likely to have a much, much bigger job ahead of you.

--
Craig Ringer



--
Jan Vodička

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Jan Vodička
Дата:
Сообщение: Re: BUG #7590: Data corruption using pg_dump only with -Z parameter
Следующее
От: Thom Brown
Дата:
Сообщение: pg_ctl restart issue with relative paths