Re: [GENERAL] Invalid field size - Mailing list pgsql-general

From Adrian Klaver
Subject Re: [GENERAL] Invalid field size
Date
Msg-id fe69f50c-6827-66ce-686f-c0886b07dc7f@aklaver.com
Whole thread Raw
In response to Re: [GENERAL] Invalid field size  (Moreno Andreo <moreno.andreo@evolu-s.it>)
Responses Re: [SPAM] Re: [GENERAL] Invalid field size  (Moreno Andreo <moreno.andreo@evolu-s.it>)
List pgsql-general
On 07/05/2017 01:05 AM, Moreno Andreo wrote:
> Il 04/07/2017 20:51, Daniel Verite ha scritto:
>>     Tom Lane wrote:
>>
>>> Moreno Andreo <moreno.andreo@evolu-s.it> writes:
>>>> So the hint is to abandon manual COPY and let pg_dump do the hard work?
>>> If it is a newline-conversion problem, compressed pg_dump archives would
>>> be just as subject to corruption as your binary COPY file is.
>> It's mentioned in [1] that the signature at the beginning of these files
>> embed a CRLF to detect this newline-conversion problem early on,
>> so I would expect COPY IN to stumble on a corrupted signature
>> and abort earlier in the process, if that conversion occurred.
>> Instead the report says it fails after a number of tuples:
> Given what you said, can I assume it's a file transfer or an
> hardware-driven (pendrive) problem?

Daniel also mentioned the harddrive as a possible source of error. I
would say monitoring where and when the issues appear may help with
determining the source.

>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: [GENERAL] 64bit initdb failure on macOS 10.11 and 10.12
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] building extension with large string inserts