From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Jan Vodička <hrtlik(at)gmail(dot)com> |
Cc: | Ryan Kelly <rpkelly22(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7590: Data corruption using pg_dump only with -Z parameter |
Date: | 2012-10-13 12:12:14 |
Message-ID: | 50795A9E.40204@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Vodička | 2012-10-13 12:14:37 | Re: BUG #7590: Data corruption using pg_dump only with -Z parameter |
Previous Message | Craig Ringer | 2012-10-13 12:08:40 | Re: BUG #7590: Data corruption using pg_dump only with -Z parameter |