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 <ring...@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/~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
