Re: Trouble with COPY IN

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-08-31 18:13:47
Message-ID: alpine.BSO.2.00.1008311410310.1495@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:

> On Tue, 20 Jul 2010, Matthew Wakeling wrote:
>> So, should the unlocking happen elsewhere, or should endCopy not require a
>> lock?
>
> Or a third option. We should delay the processing of the "Z" (Ready for
> query) message until after the endCopy has been called.
>
> I have still not been able to create a test that provokes this bug. I do not
> understand under what conditions the server will do this, but sometimes it
> will respond with a "C" and a "Z" before the endCopy message has actually
> been sent to it. Maybe it is keying off the "-1" (no further rows) part of
> the binary copy. In any case, I am including a patch here which seems to fix
> the driver for my application. When the driver receives a "C" message
> (command finished), and block is set to false, then we can assume that a
> little later on we will call processCopyResults again very soon with block
> set to true. Instead of setting block to true, finish processing of messages
> in order to delay seeing the "Z" message until after the endCopy method has
> been called.
>
> The patch also contains a simple test for binary copy in, although it does
> not exercise this bug.

I've applied a patch to CVS to implement a variant of this that is more
selective of what it ignores. It peeks into the protocol stream and
ignores all CommandComplete messages while we aren't blocking (which
means that the driver thinks it isn't done yet).

Kris Jurka

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-08-31 18:19:24 Re: Assertion failure on HEAD (or at least git copy of it)
Previous Message Alvaro Herrera 2010-08-31 18:08:58 pg_resetxlog display bogosity

Browse pgsql-jdbc by date

  From Date Subject
Next Message Fabien JALABERT 2010-09-01 07:40:27 Re: JDBC: "transaction aborted"
Previous Message Pif 2010-08-31 15:50:47 JDBC: "transaction aborted"