Re: [SPAM] Re: [GENERAL] Invalid field size
От | Adrian Klaver |
---|---|
Тема | Re: [SPAM] Re: [GENERAL] Invalid field size |
Дата | |
Msg-id | e20d6d0c-fd72-846c-c19b-39c06ac698bb@aklaver.com обсуждение исходный текст |
Ответ на | Re: [SPAM] Re: [GENERAL] Invalid field size (Moreno Andreo <moreno.andreo@evolu-s.it>) |
Ответы |
Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size
|
Список | pgsql-general |
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. > 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 > > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: