From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Moreno Andreo <moreno(dot)andreo(at)evolu-s(dot)it>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Invalid field size |
Date: | 2017-07-05 14:33:28 |
Message-ID: | fe69f50c-6827-66ce-686f-c0886b07dc7f@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)andreo(at)evolu-s(dot)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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-07-05 14:57:12 | Re: building extension with large string inserts |
Previous Message | Adrian Klaver | 2017-07-05 14:29:38 | Re: 64bit initdb failure on macOS 10.11 and 10.12 |