Re: [HACKERS] COPY problems with psql / libpq

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] COPY problems with psql / libpq
Дата
Msg-id 21145.948384151@sss.pgh.pa.us
обсуждение исходный текст
Ответ на COPY problems with psql / libpq  ("Oliver Elphick" <olly@lfix.co.uk>)
Ответы Re: [HACKERS] COPY problems with psql / libpq  (Patrick Welche <prlw1@newn.cam.ac.uk>)
Re: [HACKERS] COPY problems with psql / libpq  ("Oliver Elphick" <olly@lfix.co.uk>)
Re: [HACKERS] COPY problems with psql / libpq  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
"Oliver Elphick" <olly@lfix.co.uk> writes:
> I found that if I broke the first 1000 records into 2 equal parts, all
> of them were added correctly without error; so I conclude that data
> is being buffered and lost somewhere in psql or libpq, and the problem is
> dependent on the amount of data being copied.

I have the following note in my (much too long) to-do list:

: psql.c doesn't appear to cope correctly with quoted newlines in COPY data;
: if one falls just after a buffer boundary, trouble!
: Does fe-exec.c work either??

(This note is some months old, and may or may not still apply since
Peter's rework of psql.)  It could be that your dataset is hitting this
problem or a similar one.  A buffer-boundary problem would explain why
the error seems to be so dataset-specific.

> copy address from stdin;
> -- 1000 records written
> select count(*) from address;
> PQexec: you gotta get out of a COPY state yourself.

It sure sounds like psql is failing to recognize the trailing \.
of the COPY data.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] A notice for too long names
Следующее
От: Robert Davis
Дата:
Сообщение: off topic