Simone Tellini <tellini@areabusiness.it> writes:
> here's a bit of data: the \connect you can see is at line 94382
Okay, the problem with this file is fairly obvious after looking at it
with od -c:
00000d0 \n \r \n \ c o n n e c t - p o
00000e0 s t g r e s \r \n C O P Y " i n
00000f0 t e r r o g a z i o n i " F
0000100 R O M s t d i n ; \r \n 9 7 \t 2
0000110 0 0 0 0 5 1 2 \t B a n c a I n
0000120 t e s a e C e n t r o C o
0000130 n t a b i l e C o m i t d i
0000140 P a r m a \t 4 \t V E R B A L E
0000150 D E L C O N S I G L I O C
0000160 O M U N A L E \r \ \r \n S E D U
0000170 T A D E L 1 2 M A G G I O
The newlines in the file have been translated to \r\n, which messes up
the backslash escaping. It looks to me like the string data that was
originally dumped contained CR/LF newline sequences (\r\n), which
would have been emitted by COPY as \r\\n (ie, carriage return,
backslash, newline). What's coming back in is carriage return,
backslash, carriage return, newline --- so the backslash uselessly
quotes the second carriage return and the newline is taken as the end
of the line of COPY data. I see a result like so:
psql:tellini.sql:11: ERROR: copy: line 2, pg_atoi: error in "SEDUTA DEL 12 MAGG
": can't parse "SEDUTA DEL 12 MAGGIO 2000
psql:tellini.sql:11: lost synchronization with server, resetting connection
I suppose you are working under Windows, or have copied the file into
Windows at some point. You need to find a way to avoid corrupting the
data file with Windows newline conversion.
regards, tom lane