Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline"
От | Tom Lane |
---|---|
Тема | Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline" |
Дата | |
Msg-id | 19513.1051675083@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline" ("Ron Mayer" <ron@intervideo.com>) |
Ответы |
Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline"
|
Список | pgsql-general |
"Ron Mayer" <ron@intervideo.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
В списке pgsql-general по дате отправления: