Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly

Поиск
Список
Период
Сортировка
От Lee Joramo
Тема Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly
Дата
Msg-id 19341204144422.24648@smtp.acsol.net
обсуждение исходный текст
Ответ на Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly
Список pgsql-general
And the solution is:

    DELETE INDEX classifieds_adcopy

By deleteing the index, everything started to work correctly. Even after
recreating the index, everyting worked after multiple tests.

I came to this conclusion after much examination of the 'bad line' that
was causing my problems. I created a simple Python script to loop over
the 'adcopy' field of the bad line. For every loop it would add another
character of the adcopy, save it to a file and then issue a "COPY
classifieds FROM 'file'" to import the single line. For example the
following 8 lines represent the first 8 files that were generated:

825<TAB><TAB>f<TAB><TAB>f<TAB>N
825<TAB><TAB>f<TAB><TAB>f<TAB>Ne
825<TAB><TAB>f<TAB><TAB>f<TAB>Nee
825<TAB><TAB>f<TAB><TAB>f<TAB>Need
825<TAB><TAB>f<TAB><TAB>f<TAB>Need
825<TAB><TAB>f<TAB><TAB>f<TAB>Need m
825<TAB><TAB>f<TAB><TAB>f<TAB>Need mo
825<TAB><TAB>f<TAB><TAB>f<TAB>Need more

I also preformed this test with many other lines of data that I believed
to be good. The results of these tests confirmed to me that only the one
bad line was responsible. The good lines always loaded, the bad line
always failed. However as I repeatedly preformed this test on 'bad line',
it  failed in an inconsistent way:

Failure 1:
825<TAB><TAB>f<TAB><TAB>f<TAB>Need more growin
Failure 2:
825<TAB><TAB>f<TAB><TAB>f<TAB>Nee
Failure 3:
825<TAB><TAB>f<TAB><TAB>f<TAB>Need more growing room ? Cozy up by one of
And so on ...

At this point, I thought that maybe the index was corrupted.

But this raises other questions. Should I be concerned about other
corruption to the database? What can I do to prevent this from happening
again. Should I delete the indexes before I preform a 'COPY table FROM'
operation, and then recreate the indexes?

Thanks very much for your help.

--
Lee A. Joramo                      ljoramo@nickads.com
The Nickel Want Ads                www.nickads.com
Internet Manager                   970-242-5555


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

Предыдущее
От: "Brett W. McCoy"
Дата:
Сообщение: Re: starting PGSQL automatically on Redhat 6.2
Следующее
От: Miles Thompson
Дата:
Сообщение: Re: drop table and references