From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ron Mayer" <ron(at)intervideo(dot)com> |
Cc: | "PostgreSQL General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline" |
Date: | 2003-04-30 03:58:03 |
Message-ID: | 19513.1051675083@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Ron Mayer" <ron(at)intervideo(dot)com> writes:
> The last dozen lines or so are... (sorry if there are any typos,
> copy/paste not working).
> ERROR: CopyReadAttribute: Literal carriage return data value
> found in input that has newline termination; use \r
> CONTEXT: COPY FROM, line 146178
> IN: CopyReadAttribute (copy.c:1650)
> FATAL: Socket command type
> unknown
> IN: SocketBackend (postgres.c:294)
This is odd and disturbing. 7.2 and later servers should never generate
an unescaped \r in COPY output, so the first error shouldn't appear;
and even if it did, the new FE/BE protocol is supposed to prevent loss
of message-boundary sync, which the second error suggests is happening
anyway. It's really not clear what's being sent or who's at fault.
Unfortunately, I can't think of any painless method of tracing down an
error that is happening 146178 lines into a bulk COPY :-(. If you are
running this across a TCP socket, maybe you could capture the traffic
with tcpdump --- if so, looking at the last few dozen packets in each
direction would be mighty useful ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | ed despard | 2003-04-30 04:00:51 | rules question |
Previous Message | Martijn van Oosterhout | 2003-04-30 03:48:30 | Re: Creating a functional index on a cast? |