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

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-jdbc by date

Next:From: Fabien JALABERTDate: 2010-09-01 07:40:27
Subject: Re: JDBC: "transaction aborted"
Previous:From: PifDate: 2010-08-31 15:50:47
Subject: JDBC: "transaction aborted"

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