Re: Mixed up protocol packets in server response? - Mailing list pgsql-general

From Michal Politowski
Subject Re: Mixed up protocol packets in server response?
Date
Msg-id 20110603130357.GA7961@meep.pl
Whole thread Raw
In response to Re: Mixed up protocol packets in server response?  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Mixed up protocol packets in server response?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Mixed up protocol packets in server response?  (David Boreham <david_list@boreham.org>)
List pgsql-general
On Thu,  2 Jun 2011 08:50:30 +0800, Craig Ringer wrote:
> On 1/06/2011 9:06 PM, Michal Politowski wrote:
>
> >What may be the cause of this weird problem? Is it some known or unknown bug in
> >8.3.4 or is the application/Java side more suspected?
>
> It'd be really helpful if you could collect and examine a trace of
> the client/server communication using WireShark. That way you can
> confirm whether it is (as Tom suspects) the client side mangling its
> buffers, or whether the server really did send the nonsensical
> sequence.

Actually my own money is with Tom's. It's very hard to believe Postgres
would do something like this, unless it were some obvious and long fixed bug in 8.3.4.

Still, trying to trace the communication makes sense, if I can convince the
owners of the system to let me do it. Unfortunately this is an
"one in a million of successful queries" (actually two in much more than a million)
problem. And the next run of the application seems not to have hit it, yet.

Thinking aloud: If this is, as it is to be suspected, an application-side problem,
there is at first sight not much space in the application where it could hide. The data is
mixed up in a driver buffer, two method calls from the standard library
socket code. There is the VisibleBufferedInputStream there. Could it do
something like this? Maybe if the connection was erroneously used from two threads
concurrently? The connections are pooled via commons-dbcp BasicDataSource
and queries are executed via Spring JdbcTemplate within Spring-configured
transaction. No passing connections by hand anywhere, everything should be
nicely thread-bound. Still, if not here, where could it go wrong?

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

pgsql-general by date:

Previous
From: "Rob Richardson"
Date:
Subject: PostgreSQL service won't start after bad computer time
Next
From: "Marc Mamin"
Date:
Subject: Re: Question about configuration and SSD