On Tue, June 20, 2006 10:44 am, Tom Lane wrote:
> 78 would be ASCII 'N', but that's not really significant AFAICS. The
> problem here is that the frontend and backend have lost sync: the server is
> expecting to find a message beginning at a place in the frontend data
> stream that evidently isn't the start of a message. In short, the
> frontend has sent corrupted data of some sort.
> Martijn's theory of inadequately locked threaded access is certainly one
> likely way this can happen, but it's not the only one. It might be useful
> for you to capture the data stream (with something like tcpdump) and try
> to get more information about the nature of the corruption. Frequently, if
> you can identify "ah-hah, THIS data is being inserted into the middle of
> THAT" or whatever, the cause becomes obvious.
> Also, before you spend too much time on this, make sure your DBI and
> DBD::Pg modules are up-to-date. If it's a bug in that level, it'd be
> foolish to waste much of your own time chasing it.
If you look at his example code, he's not even using DBI- he's using Pg.pm
which is for all practical purposes deprecated and supplanted by DBD::Pg.
In response to
pgsql-interfaces by date
|Next:||From: Bruno Wolff III||Date: 2006-06-20 20:41:48|
|Subject: Re: help with error message from perl Pg|
|Previous:||From: Tom Lane||Date: 2006-06-20 14:55:39|
|Subject: Re: help with error message from perl Pg |
pgsql-general by date
|Next:||From: Alex Turner||Date: 2006-06-20 17:18:11|
|Subject: Re: Database Clustering on multiple harddisk|
|Previous:||From: Aaron Koning||Date: 2006-06-20 17:06:25|
|Subject: Re: Exporting data from view|