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

Re: invalid message format and I/O error while comunicating with backend

From: Kris Jurka <books(at)ejurka(dot)com>
To: Sergi Vera <svera(at)emovilia(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: invalid message format and I/O error while comunicating with backend
Date: 2008-04-30 23:34:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
This appears to be a thread safety related problem.  I believe your code 
has one thread setting the parameter values and another thread executing 
the prepared statement at the same time.  The executor does two passes 
through the parameter list, once to calculate a total message length and 
another time to send the values.  If the contents change between the 
length calculation and the message sending we'll have the wrong length 
and the whole client-server communication gets messed up.  The attached 
test case demonstrates this failure mode.

I'm unsure how hard we should try to fix this, there are a couple of 

1) Do nothing.  It's really a client problem and they shouldn't be 
setting and executing at the same time.

2) Just copy the parameters at execution time so we get a consistent 
view of them.  This may not be exactly what the user wants though if the 
order things actually execute is:  execute, set, copy instead of 
execute, copy, set.

3) Go through all the PreparedStatement functions making most of them 
synchronized so that you cannot set while an execute is running.

Kris Jurka

Sergi Vera wrote:
> Hi!
> I've been a little busy thoose days and was unable to work on this, but 
> I've made the tcpdump session that you requested and
> here are the results
> Kris Jurka escribió:
>> Sergi Vera wrote:
>>> Thanks Kris for the help
>>> Adding loglevel=2 dind't add any more info on logs, and it will be 
>>> not easy to make a self contained program, but I have attached the 
>>> result of
>> The loglevel=2 logging will go to the driver's System.out not into the 
>> server error log.
>>> tcpdump -vvv -i lo -w pgsqlerror2.dat
>> This only captures the start of each packet so it doesn't have the 
>> whole thing.  Could you recapture with:
>> tcpdump -n -w pgsqlerror3.dat -s 1514 -i any tcp port 5432
>> This ups the capture size (-s 1514) and also filters out the unrelated 
>> UDP traffic you've got going on.
>>> Browsing through the first failing pgsql data chunk, one can see that:
>>> The last data has column lenght -1 which seems strange even if I 
>>> don'k know anything of this particular protocol
>> -1 length indicates a NULL value, so that's expected.

Description: text/java (1.5 KB)

In response to


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2008-05-01 02:43:00
Subject: Re: BLOB is read into memory instead of streaming (bug?)
Previous:From: Andrew PerepelytsyaDate: 2008-04-30 19:27:50
Subject: BLOB is read into memory instead of streaming (bug?)

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