By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,811 Members | 1,978 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,811 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Nov 12 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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

Nov 12 '05 #2

P: n/a
> > 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

Nov 12 '05 #3

P: n/a
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

Nov 12 '05 #4

P: n/a
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

Nov 12 '05 #5

P: n/a
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

Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.