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

From Michal Politowski
Subject Mixed up protocol packets in server response?
Date
Msg-id 20110601130649.GA21333@meep.pl
Whole thread Raw
Responses Re: Mixed up protocol packets in server response?
Re: Mixed up protocol packets in server response?
List pgsql-general
I have an instance of what looks like a weird mixup of data returned by the server.
This is observed in a Java application using the 9.0-801.jdbc4 JDBC driver
connecting to an 8.3.4 server (yes, it's old) running on Solaris.

The application hung waiting for the result of one
select * from a_table where a_field = parameter;

Looking at it with a debugger I see that:
1. it waits in:
    SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) line: not available [native method]
    SocketInputStream.read(byte[], int, int) line: 129
    VisibleBufferedInputStream.read(byte[], int, int) line: 219
    PGStream.Receive(byte[], int, int) line: 460
    PGStream.ReceiveTupleV3() line: 365
    QueryExecutorImpl.processResults(ResultHandler, int) line: 1814
    QueryExecutorImpl.execute(Query, ParameterList, ResultHandler, int, int, int) line: 257
    Jdbc4PreparedStatement(AbstractJdbc2Statement).execute(Query, ParameterList, int) line: 500
    Jdbc4PreparedStatement(AbstractJdbc2Statement).executeWithFlags(int) line: 388
    Jdbc4PreparedStatement(AbstractJdbc2Statement).executeQuery() line: 273
because it expects a field of size = 825767394 (l_size in ReceiveTupleV3)
which is much more than the whole result should be.

2. then looking at the answer array in ReceiveTupleV3:
A few first fields have the expected values,
then answer[3] has the expected
size but somewhere in the middle it changes from field 3 of the first row
of the result to the middle of field 3 of the last row of the result.
Then of course there are 4 bytes of this field that as a 32-bit integer
have the value of 825767394.
Then answer[4] obviously has 825767394 elements. And it continues with the
field 3 of the last row and then it contains the 4-byte length and then
value of the field 4 (last) of the last row of the result - so the end of a
DataRow message.
Then a CommandComplete message with the tag "SELECT",
then a ReadyForQuery message with the status indicator "T".
And then there is the rest of the field 3 of the first row, then length and
value for the field 4 of the first row and then the DataRow messages for
the following rows of the result. The last one up until the place where
it got mixed up before.

So it looks like the server wanted to send
D row 1, D row 2, D row 3, D row 4, C SELECT, Z T
but the application sees
D ro, ow 4, C SELECT, Z T, w 1, D row 2, D row 3, D r

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?

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

pgsql-general by date:

Previous
From: Pete Chown
Date:
Subject: Re: Consistency of distributed transactions
Next
From: jlhgis
Date:
Subject: Re: troubles with initdb