On 07/04/2017 10:57 AM, Moreno Andreo wrote:
Il 04/07/2017 19:28, Tom Lane ha scritto:
Moreno Andreo <moreno.andreo@xxxxxxxxxx> 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...
Well that leads to four observations:
1) How the user handles their backup files is something that might need
to be known.
2) By using your own backup code procedure you have taken possession of
any resultant bugs:( The list might be able to help with those anyway,
if it is possible for you to share the code you use to create the backups.
3) 1) and 2) could be moot if Daniel's hardware corruption theory is
correct.
4) This is probably not going to be solved until you are able to access
the actual file(s) in question.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
