To: Michael Fuhr <mike@fuhr.org>
Cc: Scott Cain <cain@cshl.edu>, pgsql-interfaces@postgresql.org
Subject: Re: DBD::Pg and "invalid frontend message type 10" 
In-reply-to: <20050824133453.GA50029@winnie.fuhr.org> 
References: <1124889034.2940.132.camel@localhost.localdomain>
	<20050824133453.GA50029@winnie.fuhr.org>
Comments: In-reply-to Michael Fuhr <mike@fuhr.org>
	message dated "Wed, 24 Aug 2005 07:34:53 -0600"
Date: Wed, 24 Aug 2005 11:10:06 -0400
Message-ID: <26062.1124896206@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Fuhr <mike@fuhr.org> writes:
> On Wed, Aug 24, 2005 at 09:10:34AM -0400, Scott Cain wrote:
>> I am a developer of a PostgreSQL powered application that, naturally,
>> works fine in my hands, using verison 7.4.* (most recently, 7.4.8).  I
>> have a user, however, that is getting this error message:
>> 
>> DBD::Pg::db do failed: FATAL:  invalid frontend message type 10
>> 
>> Can someone shed some light on where to start looking for the source of
>> this problem?  I'm guessing the message is coming from postgres, since I
>> can't find a string like that in DBD::Pg.

> The message comes from the PostgreSQL backend; it's received a
> message it doesn't understand.

Since 10 is the ascii code for line-feed, I wonder if this could
indicate an unwanted newline format conversion someplace.  In particular
I'm imagining something like this:

* frontend thinks it's sending 'Q' message type, message length,
  and a query string that ends with \n:
	Q 0 0 0 42 SELECT ... \n
* some evil code changes this to
	Q 0 0 0 42 SELECT ... \r \n
* backend receives and executes
	Q 0 0 0 42 SELECT ... \r
  which is perfectly OK
* next time backend tries to read a message, it gets the \n
  which leads to the reported complaint

I've glossed over some details but in general it seems like something
like this could be happening, if you are using the V3 protocol which
relies on message length words.

			regards, tom lane