Re: BUG #7590: Data corruption using pg_dump only with -Z parameter
| От | Craig Ringer |
|---|---|
| Тема | Re: BUG #7590: Data corruption using pg_dump only with -Z parameter |
| Дата | |
| Msg-id | 50795A9E.40204@ringerc.id.au обсуждение исходный текст |
| Ответ на | Re: BUG #7590: Data corruption using pg_dump only with -Z parameter (Jan Vodička <hrtlik@gmail.com>) |
| Ответы |
Re: BUG #7590: Data corruption using pg_dump only with -Z parameter
|
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: