Thread: pqReadData() -- read() failed: errno=32
Hi, cobalt 2.2.16 psql 7.2.3 DBI 1.32 I get this error, as in subject:- pqReadData() -- read() failed: errno=32 and then followed by this pqReadData() -- backend closed the channel unexpectedly. I can find no reference to errno=32 in the mailing lists. If i define and connect the database handle within the function that does my processing, then i get no errors (but very slow processing due to connecting on each event). If i define and connect the database handle as a global variable outside of the function, then i get that error on the first insert. Any ideas ? Craig
On Thursday 18 December 2003 12:23, Craig Stratton wrote: > Hi, > > cobalt 2.2.16 > psql 7.2.3 > DBI 1.32 > > I get this error, as in subject:- > pqReadData() -- read() failed: errno=32 > and then followed by this > pqReadData() -- backend closed the channel unexpectedly. > > I can find no reference to errno=32 in the mailing lists. From memory and google, it's a broken pipe, traditionally from php's persistent connections. Assuming a backend isn't dying, I'm a bit puzzled. Check your logs and see if all is OK. > If i define and connect the database handle within the function that does > my processing, then i get no errors (but very slow processing due to > connecting on each event). > > If i define and connect the database handle as a global variable outside > of the function, then i get that error on the first insert. Can you give a short example of what works and what doesn't. -- Richard Huxton Archonet Ltd
> > I get this error, as in subject:-
> > pqReadData() -- read() failed: errno=32
> > and then followed by this
> > pqReadData() -- backend closed the channel unexpectedly.
> >
> > I can find no reference to errno=32 in the mailing lists.
>
> From memory and google, it's a broken pipe, traditionally from php's
> persistent connections. Assuming a backend isn't dying, I'm a bit puzzled.
> Check your logs and see if all is OK.
This is running as a cgi script, not php. The backend dies afterwards.
I think it is dbi/thread/child related, so i modified the code, but still no
joy.
I am fairly sure its dbi thread related still though.
>
> > If i define and connect the database handle within the function that
does
> > my processing, then i get no errors (but very slow processing due to
> > connecting on each event).
> >
> > If i define and connect the database handle as a global variable
outside
> > of the function, then i get that error on the first insert.
>
> Can you give a short example of what works and what doesn't.
1) connect within sub
my $dbv;
sub SQLLogging {
$dbv = DBI->connect("DBI:Pg:dbname=dbv","admin", "", {'PrintError' => 0});
and then all following inserts work fine
2) connect outside of sub
my $dbv;
$dbv = DBI->connect("DBI:Pg:dbname=dbv","admin", "", {'PrintError' => 0});
sub SQLLogging {
and then i get the error on the first insert attempt
3) connect outside, connect inside if not defined (in case missed by thread
fork)
my $dbv;
$dbv = DBI->connect("DBI:Pg:dbname=dbv","admin", "", {'PrintError' => 0});
sub SQLLogging {
unless(defined($dbv)){
$dbv = DBI->connect("DBI:Pg:dbname=dbv","admin", "", {'PrintError' =>
0});
}
this gives me the same problem as (2)
I didn't write the rest of the script, only the logging routine, so until i
go back and study the code, i am not sure where the fork(s) happen.
I was hoping that the errno=32 would give a clear indication that there was
a client/connection problem to follow up.
Regards
Craig
On Thu, Dec 18, 2003 at 02:30:55PM -0000, Craig Stratton wrote: > This is running as a cgi script, not php. The backend dies afterwards. > I think it is dbi/thread/child related, so i modified the code, but still no > joy. > I am fairly sure its dbi thread related still though. Is this running within some persistent model? PersistentPerl, mod_perl, whatever? It may be a problem related to this: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines Even if it's not, you can try using "our" instead of "my" and see if that fixes it. If it does, then probably that's the problem. If it doesn't, maybe another of the solutions proposed there will, or maybe not. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Vivir y dejar de vivir son soluciones imaginarias. La existencia está en otra parte" (Andre Breton)
Richard Huxton <dev@archonet.com> writes:
> On Thursday 18 December 2003 12:23, Craig Stratton wrote:
>> I can find no reference to errno=32 in the mailing lists.
> From memory and google, it's a broken pipe,
It would be a good idea to check in /usr/include/errno.h before
assuming that 32 means EPIPE on a Cobalt. I'm a bit suspicious
of that because I can't imagine why read() would return EPIPE.
regards, tom lane
On Thursday 18 December 2003 14:30, Craig Stratton wrote: > > > I get this error, as in subject:- > > > pqReadData() -- read() failed: errno=32 > > > and then followed by this > > > pqReadData() -- backend closed the channel unexpectedly. > > > > > > I can find no reference to errno=32 in the mailing lists. > > > > From memory and google, it's a broken pipe, traditionally from php's > > persistent connections. Assuming a backend isn't dying, I'm a bit > > puzzled. Check your logs and see if all is OK. > > This is running as a cgi script, not php. The backend dies afterwards. > I think it is dbi/thread/child related, so i modified the code, but still > no joy. > I am fairly sure its dbi thread related still though. > 3) connect outside, connect inside if not defined (in case missed by thread > fork) What threads and forking? Are you re-using the same connection in different threads/processes? -- Richard Huxton Archonet Ltd