Re: [HACKERS] Trouble with COPY IN
От | Kris Jurka |
---|---|
Тема | Re: [HACKERS] Trouble with COPY IN |
Дата | |
Msg-id | alpine.BSO.2.00.1007281249290.9018@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Trouble with COPY IN (James William Pye <lists@jwp.name>) |
Ответы |
Re: [HACKERS] Trouble with COPY IN
|
Список | pgsql-jdbc |
On Wed, 28 Jul 2010, James William Pye wrote: > > hrm, I suppose a lazy way around that problem would be to suspend all > client messages(client_min_messages) during COPY IN. Tho, I guess one > would still have to contend with NotificationResponse, and > ParameterStatus.. Technically you won't get NotificationResponse until transaction end, so you don't need to worry about that mid copy. > I don't think you would have to peek in. If the interface were to always > hold onto the last message or last n-bytes submitted to be sent, it > would be able to send the possible CopyData(EOF) and CopyDone once the > COPY operation (at the interface level) is closed/shutdown/terminated. > Granted, this is dependent on CopyData(EOF) not being in the middle of > regular CopyData, but I gather that that would end in an ErrorResponse > anyways. One of the key points of confusion is that CopyData(EOF) does not result in an error. It results in ignoring any futher data. The problem I have is that for text mode it waits for CopyDone, but in binary mode it ends the copy sequence immediately. Additionally the interface exposed by the JDBC driver lets the user write arbitrary CopyData bytes to the server, so without parsing all of that we don't know whether they've issued CopyData(EOF) or not. Kris Jurka
В списке pgsql-jdbc по дате отправления: