Обсуждение: COPY problem with bad dates
It looks like when a bad date is entered using COPY the backend connection gets killed. I noticed this when having a problem loading a database with several copies in one transaction. The backend died consistantly at the same point, but not near where the bad dates were. I eventually found the bad dates and corrected the problem with the load. However I noticed that the error message I got indicated the backend died, so I thought I should try to get a simpler case that shows the same problem. Below is a short psql example run against a 7.3 database that also gets the backend to crash, though not in the middle of a large transaction. bruno=> create table test (col1 timestamp); CREATE TABLE bruno=> copy test from stdin; Enter data to be copied followed by a newline. End with a backslash and a period on a line by itself. >> 11/31/02 >> \. ERROR: copy: line 1, Bad timestamp external representation '11/31/02' lost synchronization with server, resetting connection
On Wed, Dec 18, 2002 at 09:14:18 -0600, Bruno Wolff III <bruno@wolff.to> wrote: > It looks like when a bad date is entered using COPY the backend connection > gets killed. I just tried it with 7.3.1 and get the same error.
Bruno Wolff III <bruno@wolff.to> writes: > ERROR: copy: line 1, Bad timestamp external representation '11/31/02' > lost synchronization with server, resetting connection This is not a backend crash, this is libpq's standard operating procedure for recovering from an error during COPY. If we had a less brain-dead COPY protocol (ie, one that actually had provisions for error abort), we'd not have to do this. See plans for 7.4 protocol revisions ... regards, tom lane