Re: [HACKERS] Trouble with COPY IN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: 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-23 14:11:36
Message-ID: 9653.1279894296@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

Kris Jurka <books(at)ejurka(dot)com> writes:
> On 7/23/2010 6:40 AM, Tom Lane wrote:
>> I believe this is a misunderstanding of the protocol spec. The spec is
>> (intended to say that) we'll continue to accept data after reporting an
>> error, not that we will silently swallow an incorrect data stream and
>> not complain about it. Which is what this patch will do.

> All this does is make binary mode match text mode.

The fact that text mode eats data after \. is a backwards-compatibility
kluge to match the behavior of pre-7.4 COPY. It could very legitimately
be argued to be a bug in itself. I don't think that we should make
binary mode match it. The main concrete reason why not is that binary
mode has almost no redundancy. It would be really easy for the code
change you suggest to result in data being silently discarded with no
hint of what went wrong.

After some reflection, I think the real issue here is that the JDBC
driver is depending on a behavior not stated in the protocol, which
is the relative timing of FE-to-BE and BE-to-FE messages. Once you've
sent the EOF marker, the only correct follow-on for a spec-compliant
frontend is a CopyEnd message. So the backend is just sending its
response a bit sooner. There's nothing in the protocol spec forbidding
that.

I would be willing to accept a patch that avoided sending CopyEnd
immediately after receiving EOF, so long as it still threw an error
for extra data; but this is not that patch. The larger issue though
is whether it wouldn't be better to change the driver behavior instead.
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ... and you're never going to get everybody to
upgrade their server version, even if we were willing to back-patch
the change.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-23 14:57:57 Re: psql \conninfo command (was: Patch: psql \whoami option)
Previous Message Magnus Hagander 2010-07-23 13:55:15 Re: [PATCH] "could not reattach to shared memory" on Windows

Browse pgsql-jdbc by date

  From Date Subject
Next Message Kris Jurka 2010-07-23 15:35:53 Re: [HACKERS] Trouble with COPY IN
Previous Message Kris Jurka 2010-07-23 13:50:30 Re: [HACKERS] Trouble with COPY IN