Sorry to spam you guys with my noise, but for the sake of posterity,
I thought I'd reply with the solution to this problem.
I learned a lot about the PGSQL protocol during this time. So, I
ended up getting a Ethereal installed on a machine so I could follow
the protocol and see what exactly was being sent to it. As it turns
out, a separate piece of software on this server, which uses a single
database handle to do its work was somehow sending an error message
from another perl module as a message to the database.
It's a guess that somehow it got its file handles mixed up or
something along those lines. So the "73" (PgSQL 7.4) or the
"I" (PgSQL 7.3) was truly an I since the message going to the server
was something like:
"Invalid blah blah blah"
instead of:
"Q....SELECT * FROM TABLE"
Mystery solved. I've disabled the offensive code until I can more
closely investigate in a controlled environment. Give that we didn't
really need it, turning it off is an adequate solution for a
production server.
--Joel
> On Feb 4, 2006, at 1:16 AM, Tom Lane wrote:
>
>> Joel Richard <postgresql@joelrichard.com> writes:
>>> ... we occasionally get the following message in our apache log
>>> file. I'm looking for information on what it means:
>>
>>> DBD::Pg::db selectrow_array failed: FATAL: Socket command type I
>>> unknown
>>
>> This looks to me like a protocol-level incompatibility: probably the
>> client code is sending data in a slightly different format than the
>> server is expecting, or one side or the other is off-by-one about
>> message lengths, or something like that. One way or another the
>> server is receiving an 'I' when it wasn't expecting that.
>>
>> I'm not aware of any such bugs on the server side in 7.3.4. What I
>> suspect is a problem on the DBD::Pg side, where you did not specify
>> what version you are using ... but if it's recent, it probably thinks
>> that talking to 7.3.4 is a legacy problem ...
>>
>> regards, tom lane
>
Joel Richard
The Richard Group
joel@richard-group.com
703-584-5802
