> In 7.3 there is only one use of PGRES_NONFATAL_ERROR, and it's this:
>
> ExecStatusType
> PQresultStatus(const PGresult *res)
> {
> if (!res)
> return PGRES_NONFATAL_ERROR;
> return res->resultStatus;
> }
>
> So what you're seeing is a NULL PGresult pointer. (7.4 uses
> PGRES_FATAL_ERROR for this case, which I think is saner.)
That gives me the start of an idea...
> The most likely causes for a NULL result from PQexec would be
> out-of-memory or failure to send the query due to communication
> failure. Although PQresultErrorMessage can tell you nothing
> (since there is no result), you should find something informative
> in the connection's error status (PQerrorMessage).
I don't think there's any communication failure, since the app and server
are running on the same machine. But I'm using a pool of connections, so
perhaps some prior thread abused a connection and left it in a
non-functioning state. I'll have to take a close look at some of the error
handling, at least make sure that everything is logged by my app, and of
course get the connection's error status when I see PGRES_NONFATAL_ERROR.
Thanks.
--
Scott Ribe
[EMAIL PROTECTED]
http://www.killerbytes.com/
(303) 665-7007 voice
---------------------------(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
