On 07/04/2017 10:13 AM, Moreno Andreo wrote:
Il 04/07/2017 18:25, Adrian Klaver ha scritto:
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.
On the basis of what Daniel wrote, I think you're absolutely right.
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
So the hint is to abandon manual COPY and let pg_dump do the hard work?
Not necessarily, you could modify your existing code to use the text COPY.
It means rewriting the whole backup logic, but if it has to be done,
I'll manage to do it.
Thanks!
Moreno
--
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
