pqReadData() -- read() failed: errno=32

[Craig Stratton]

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


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Richard Huxton]

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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Craig Stratton]

> > 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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Alvaro Herrera]

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/...ed_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)

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Tom Lane]

Richard Huxton <de*@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

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Richard Huxton]

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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html