Re: reading cvs logs with pgadmin queries - Mailing list pgsql-general

From Dave Cramer
Subject Re: reading cvs logs with pgadmin queries
Date
Msg-id CADK3HH+Zpn5+=08FZWJPvrv8RWkrLYT-=BO95wzm8fs1LgFypQ@mail.gmail.com
Whole thread Raw
In response to Re: reading cvs logs with pgadmin queries  (Adrian Klaver <adrian.klaver@gmail.com>)
List pgsql-general
Ok, I found the offending line. It was not the pgadmin line. There was a line with a large binary insert. 

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca


On Mon, Sep 23, 2013 at 6:31 PM, Adrian Klaver <adrian.klaver@gmail.com> wrote:
On 09/23/2013 12:46 PM, Dave Cramer wrote:
OK,

I have a little more information.

Yes, in isolation I can import these lines, however something happens
after 69000 lines. These lines cause an error.

Is it the same error?

The exact error message is  ERROR:  extra data after last expected column

If so I would say the problem is in the transition between line 69000 and 69001.


I wonder if you are getting bit by some variation of the below where partial lines are getting through in spite of the PK:

http://www.postgresql.org/docs/9.3/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-CSVLOG

"The table definition above includes a primary key specification. This is useful to protect against accidentally importing the same information twice. The COPY command commits all of the data it imports at one time, so any error will cause the entire import to fail. If you import a partial log file and later import the file again when it is complete, the primary key violation will cause the import to fail. Wait until the log is complete and closed before importing. This procedure will also protect against accidentally importing a partial line that hasn't been completely written, which would also cause COPY to fail."







Dave Cramer


--
Adrian Klaver
adrian.klaver@gmail.com

pgsql-general by date:

Previous
From: Hombakazi Cynthia Jozela
Date:
Subject: Incorrect password when restarting a cluster
Next
From: Merlin Moncure
Date:
Subject: Re: Deduplication and transaction isolation level