Re: [JDBC] Trouble with COPY IN

Поиск
Список
Период
Сортировка
От James William Pye
Тема Re: [JDBC] Trouble with COPY IN
Дата
Msg-id BDD3690F-8290-4FC4-B6DE-1ED6E5558D83@jwp.name
обсуждение исходный текст
Ответ на Re: [JDBC] Trouble with COPY IN  (Kris Jurka <books@ejurka.com>)
Ответы Re: [JDBC] Trouble with COPY IN  (Matthew Wakeling <matthew@flymine.org>)
Re: [JDBC] Trouble with COPY IN  (Kris Jurka <books@ejurka.com>)
Список pgsql-hackers
On Jul 28, 2010, at 9:53 AM, Kris Jurka wrote:
> Technically you won't get NotificationResponse until transaction end, so you don't need to worry about that mid copy.

Ah, thanks for noting that. It would appear my original reading of the async section didn't get far enough beyond
"Frontendsmust be prepared to deal with these messages at any time, even when not engaged in a query.". I see the note
belowclarifying NotificationResponse. 

> 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.

That is bothersome. :\

> Additionally the interface exposed by the JDBC driver lets the user write arbitrary CopyData bytes to the server, so
withoutparsing all of that we don't know whether they've issued CopyData(EOF) or not. 

Okay, so you can't know with absolute certainty without parsing the data, but the usual case would be handled by
holdingonto the last-N bytes or so. Enough to fit the EOF and perhaps a little more for paranoia's sake. 

That's not to say that I'm missing the problem. When (not "if", "when") the user feeds data past a CopyData(EOF), it's
goingto get interesting. 

[Thinking about the logic necessary to handle such a case and avoid network buffer deadlock...]
I would think the least invasive way to handle it would be to set the CommandComplete and ReadyForQuery messages aside
whenthey are received if CopyDone hasn't been sent, continue the COPY operation as usual until it is shutdown, send
CopyDoneand, finally, "reinstate" CommandComplete and RFQ as if they were just received.. I don't think that really
accommodatesfor CopyFail as the status in RFQ will need to be "adjusted" to match what was actually done..? Well, I'm
notsure you would need to worry about NoticeResponse after a premature CommandComplete as INSERTs are no longer
happening.ugh. 


+1 for a fix.


Not directly regarding your patch, but while the discussion is in the general area.
I think it would be wise to throw an error when non-empty CopyData messages are received after CopyData(EOF). Chances
arethat the user is making a mistake and should be notified of it. 

cheers, jwp

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: page corruption on 8.3+ that makes it to standby
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: page corruption on 8.3+ that makes it to standby