Il 04/07/2017 18:25, Adrian Klaver ha scritto:
> On 07/04/2017 09:02 AM, Moreno Andreo wrote:
>> Il 04/07/2017 17:39, Adrian Klaver ha scritto:
>
>>>> So what you are saying is "in the last 5 years you've been
>>>> extremely lucky?" :-)
>>>
>>> Your original post went back and forth on whether you where lucky in
>>> the past:
>>>
>>> "... that's been working well in the last 5 years (and it's still
>>> working, since this is a single, isolated case)"
>>>
>>> "As for many error I got in the past I assume we are trying to COPY
>>> FROM corrupted data (when using cheap pendrives we get often this
>>> error)."
>> The bunch of errors I mention here is related to file management
>> (issues with file copying or unzipping), sometines I had errors like
>> "unrecognized Unicode character: 0xFF", and making a new backup
>> always resolved the error.
>> This is the very first time we have this kind of error.
>
> One could say your current error is just a variation of the above.
On the basis of what Daniel wrote, I think you're absolutely right.
>
>> If I had the source machine I'd try to make a new backup...
>
> That would be a useful data point, though given the above if it
> succeeds it mainly proves Tom's point, that using BINARY in your
> situation is a hit and miss exercise.
>
> Have you tried doing something like?:
>
> pg_dump -d production -U postgres -t projection -a > proj_txt.sql
>
> pg_dump -d production -U postgres -t projection -a -Z 5 >
> proj_txt.sql.gz
>
>
> l -h proj_txt.sql*
> -rw-r--r-- 1 aklaver users 3.2M Jul 4 09:23 proj_txt.sql
> -rw-r--r-- 1 aklaver users 560K Jul 4 09:23 proj_txt.sql.gz
So the hint is to abandon manual COPY and let pg_dump do the hard work?
It means rewriting the whole backup logic, but if it has to be done,
I'll manage to do it.
Thanks!
Moreno