Обсуждение: DBD::Pg and "invalid frontend message type 10"

Hello,

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.

Thanks,
Scott

-- 
------------------------------------------------------------------------
Scott Cain, Ph. D.                                         cain@cshl.edu
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory

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.  What's different about your system
and the user's?  At what point in the connection does the user get
the error?  Can you run a sniffer on the connection to see what's
happening?

-- 
Michael Fuhr

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

On Wed, 2005-08-24 at 11:10 -0400, Tom Lane wrote:
> 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.
> 

Wow, Tom, I have no idea what that means!  I haven't heard back from my
user whom I asked to turn on query logging so that we can see what the
server is seeing, but I suspect that the offending code may be in this
sub that is doing a COPY FROM STDIN:

sub copy_from_stdin { my $dbh      = shift; my $table    = shift; my $fields   = shift; my $file     = shift; my
$sequence= shift; my $nextval  = shift;
 
 warn "Loading data into $table table ...\n"; my $query = "COPY $table $fields FROM STDIN;"; #warn "\t".$query; my $sth
=$dbh->prepare($query); $sth->execute();
 
 open FILE, $file; while (<FILE>) {   $dbh->func($_, 'putline'); } $dbh->func('endcopy');  # no docs on this func--got
fromgoogle close FILE;
 
 $sth->finish; #update the sequence so that later inserts will work $dbh->do("SELECT setval('public.$sequence',
$nextval)FROM $table");
 
}

Does that help at all?

Thanks,
Scott

-- 
------------------------------------------------------------------------
Scott Cain, Ph. D.                                         cain@cshl.edu
GMOD Coordinator (http://www.gmod.org/)                     216-392-3087
Cold Spring Harbor Laboratory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> $dbh->func($_, 'putline');
> $dbh->func('endcopy');  # no docs on this func--got from google


Not sure what's going on exactly, but it is no doubt related
to the COPYing. Something that might help is to use the more
recent DBD::Pg COPY interfaces:

$dbh->pg_getline();
$dbh->pg_putline();
$dbh->pg_endcopy();

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200508251305
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkMN+lIACgkQvJuQZxSWSsgjqQCg8Voy1tajPfIt1lhIgDo+H/hI
ukcAoI7cD/uV5bx7olhvq2yZmBamTU+f
=Yiq+
-----END PGP SIGNATURE-----