Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size

Поиск
Список
Период
Сортировка
От Moreno Andreo
Тема Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size
Дата
Msg-id ac9d50c7-3069-f527-86a8-a8e9c5c1e53d@evolu-s.it
обсуждение исходный текст
Ответ на Re: [SPAM] Re: [SPAM] Re: [GENERAL] Invalid field size  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [SPAM] Re: [SPAM] Re: Invalid field size
Список pgsql-general
Il 04/07/2017 19:28, Tom Lane ha scritto:
> 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.  I'd say
> the hint is to be more careful about how you do the cross-machine file
> transfers.  I suspect what is really happening is you're not always
> doing that the same way, and that some of the methods allow a newline
> conversion to happen to the file while others don't.
>
>             regards, tom lane
>
>
Well, I have no control on how the user transfers back and forth among
machines.
Imagine you have a zip file where you backup your daily work. After
you've done your backup, you put it on a pendrive and go home. When
you're at home you copy this file to your computer and decompress it.
Our application works exactly the same way, except that it does not work
with raw files, but with PostgreSQL data.
So I don't know how a user handles its backup files once he has made his
backup...



В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: [GENERAL] Re: have trouble understanding xmin and xmax withupdate operations from two different sessions
Следующее
От: "Daniel Verite"
Дата:
Сообщение: Re: [GENERAL] Invalid field size