Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly - Mailing list pgsql-general

From Lee Joramo
Subject Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly
Date
Msg-id 19341204144422.24648@smtp.acsol.net
Whole thread Raw
In response to Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: COPY error: pqReadData() -- backend closed the channel unexpectedly
List 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 by date:

Previous
From: "Brett W. McCoy"
Date:
Subject: Re: starting PGSQL automatically on Redhat 6.2
Next
From: Miles Thompson
Date:
Subject: Re: drop table and references