| From: | Kris Jurka <books(at)ejurka(dot)com> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Maciek Sakrejda <msakrejda(at)truviso(dot)com>, Samuel Gendler <sgendler(at)ideasculptor(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
| Subject: | Re: Trouble with COPY IN |
| Date: | 2010-07-20 18:58:09 |
| Message-ID: | alpine.BSO.2.00.1007201455220.5084@leary.csoft.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
On Tue, 20 Jul 2010, Matthew Wakeling wrote:
> Okay, have investigated a little further. It seems that the server may be
> responding to the client a little too quickly with the "all done" message.
> Here is a sequence of events in core.v3.QueryExecutorImpl:
>
> We call startCopy(). It calls processCopyResults().
> In processCopyResults, we receive character G, and we lock.
>
> We call writeToCopy(). It calls processCopyResults().
> We receive character C.
> We receive character Z, and unlock.
>
> We call endCopy(), which tries to unlock and fails.
>
>
> So, should the unlocking happen elsewhere, or should endCopy not require a
> lock?
To me it seems like a protocol violation to receive CommandComplete(C) and
ReadyForQuery(Z) before we've issued CopyDone(c) and this should be fixed
server side.
Kris Jurka
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-07-20 19:05:11 | Re: dynamically allocating chunks from shared memory |
| Previous Message | Markus Wanner | 2010-07-20 18:54:42 | Re: dynamically allocating chunks from shared memory |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Radosław Smogura | 2010-07-20 19:14:01 | Binary protocol support for JDBC |
| Previous Message | Matthew Wakeling | 2010-07-20 14:55:18 | Re: Trouble with COPY IN |