From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Maciek Sakrejda <msakrejda(at)truviso(dot)com> |
Cc: | Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Trouble with COPY IN |
Date: | 2010-07-16 18:06:21 |
Message-ID: | alpine.BSO.2.00.1007161401530.6634@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On Fri, 16 Jul 2010, Kris Jurka wrote:
> That seems likely. What's probably necessary to reproduce this is a
> failure at the end of the data stream. An early error will be received
> and processed normally, but an error at the end will be buffered and the
> driver will think everything succeeded and try to end the copy not
> knowing that it has already failed. I think we'd need to call the
> blocking version of processCopyResults prior to endCopy to avoid this
> misleading error.
>
Actually with a little more thinking, what I said was completely bogus.
1) Blocking won't fix anything because in the success path, there's no
message to receive, so there's nothing to process.
2) The protocol docs say that after an error, CopyData,
CopyDone, and CopyFail messages are ignored, so they wouldn't be causing
this error.
So some more thought is needed here...
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-07-16 18:22:22 | Re: Synchronous replication |
Previous Message | Dimitri Fontaine | 2010-07-16 17:57:17 | Re: putting plproxy in pg_pltemplate |
From | Date | Subject | |
---|---|---|---|
Next Message | Florence Cousin | 2010-07-17 18:46:22 | Re: documentation on PGResultSetMetaData |
Previous Message | Kris Jurka | 2010-07-16 17:41:13 | Re: Trouble with COPY IN |