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

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(at)ringerc(dot)id(dot)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/~hrtlik/backup.gz>
>> <http://mstu.cz/%7Ehrtlik/**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/~hrtlik/backup.sql> <
>> http://mstu.cz/%7Ehrtlik/**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