From: | J B Bell <jbbell(at)intergate(dot)ca> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Vexing DBD::Pg problem |
Date: | 2000-10-25 15:49:03 |
Message-ID: | 20001025154903.A71069@staff.intergate.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've spent several hours today reading lots of docs, learning sneaky ways
to grant access on a whole database's worth of tables at once, and so on,
but have made next to know headway against this exact same error's coming
up everytime I try to run a certain module:
from apache logs:
[Wed Oct 25 14:47:08 2000] [error] DBD::Pg::st execute failed: pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
I am running:
postgres 7.0.2 (compiled from source)
running with -i -d2 > postgres.log 2>&1
Linux kernel 2.2.17 on a Debian system
The postgres log shows absolutely nothing; my reading on the web on similar
errors to this seems to show it as being an authorization failure of a kind.
However, auth failues get logged faithfully using a normal client connection.
I assume this has somehow to do with mod_perl. I can use the module I wrote
(Apache::AuthCookieHandler.pm, part of the Apache::AuthCookie system) from
the command line after modifying it so it doesn't need the Apache->request
object. Ordinary CGI programs can access the db in question, with the same
authentication information, without apparent difficulty.
I'm quite exhausted & would welcome with great relief any new avenues to check
out with this. I'm on the list, so no need to Cc: me. Thanks kindly to all.
--JB
--
------------------------------------------------------------------
J B Bell | /~\
Systems Administrator | ASCII \ / Against
Internet Gateway | Ribbon X HTML
| Campaign / \ Mail
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2000-10-25 16:01:03 | Re: A rare error |
Previous Message | Tom Lane | 2000-10-25 15:23:04 | Re: Delete temp tables |