Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Trouble with COPY IN

From: James William Pye <lists(at)jwp(dot)name>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Matthew Wakeling <matthew(at)flymine(dot)org>, 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: [HACKERS] Trouble with COPY IN
Date: 2010-07-28 20:19:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-jdbc
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 "Frontends must be prepared to deal with these messages at any time, even when not engaged in a query.". I see the note below clarifying 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 without parsing 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 holding onto 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 going to 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 when they are received if CopyDone hasn't been sent, continue the COPY operation as usual until it is shutdown, send CopyDone and, finally, "reinstate" CommandComplete and RFQ as if they were just received.. I don't think that really accommodates for CopyFail as the status in RFQ will need to be "adjusted" to match what was actually done..? Well, I'm not sure 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 are that the user is making a mistake and should be notified of it.

cheers, jwp

In response to


pgsql-hackers by date

Next:From: Jeff DavisDate: 2010-07-28 21:22:26
Subject: Re: page corruption on 8.3+ that makes it to standby
Previous:From: Robert HaasDate: 2010-07-28 19:49:08
Subject: Re: page corruption on 8.3+ that makes it to standby

pgsql-jdbc by date

Next:From: Craig RingerDate: 2010-07-29 02:21:44
Subject: Re: JPA and desktop apps
Previous:From: Kris JurkaDate: 2010-07-28 16:57:58
Subject: Re: Wrong SqlType for boolean columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group