Re: DBD::Pg and "invalid frontend message type 10"
От | Tom Lane |
---|---|
Тема | Re: DBD::Pg and "invalid frontend message type 10" |
Дата | |
Msg-id | 26062.1124896206@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: DBD::Pg and "invalid frontend message type 10" (Michael Fuhr <mike@fuhr.org>) |
Ответы |
Re: DBD::Pg and "invalid frontend message type 10"
|
Список | pgsql-interfaces |
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 toQ 0 0 0 42 SELECT ... \r \n * backend receives and executesQ 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
В списке pgsql-interfaces по дате отправления: