From: | "Murray S(dot) Kucherawy" <msk(at)cloudmark(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #5837: PQstatus() fails to report lost connection |
Date: | 2011-01-24 18:14:43 |
Message-ID: | F5833273385BB34F99288B3648C4F06F1341E73FCE@EXCH-C2.corp.cloudmark.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, January 24, 2011 9:42 AM
> To: Murray S. Kucherawy
> Cc: Robert Haas; pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] BUG #5837: PQstatus() fails to report lost connection
>
> >> This is complete nonsense. If you followed the documented method for
> >> using PQgetResult -- ie, keep calling it till it returns NULL, rather
> >> than assuming there will be a specific number of results --- then
> >> PQstatus would show you the bad status afterwards.
>
> > Your assertion here of "Read the result set to exhaustion, THEN check
> > connection status to see if it was bad to begin with," can be politely
> > described as counter-intuitive.
>
> [ shrug... ] I guess if your intuition is that PQstatus should be
> expected to intuit the failure of a call that hasn't happened yet,
> then it's counter-intuitive.
You're mixing internal implementation details with what the API consumer sees. I don't expect PQstatus() to do anything other than tell me that a connection is no longer usable, which is what it's documented to do. I'm fine with checking it after an error has been returned by some query-related function, which is what OpenDBX is doing. I don't know why that's "complete nonsense".
Look at the order of operations here:
0) A previous connection exists. The server is manually restarted.
1) A query is issued. This succeeds.
2) A request for results is issued. This returns non-NULL, apparently indicating at least one result object came back.
3) PQresultStatus() is called, and it returns PGRES_FATAL_ERROR.
4) PQstatus() is checked, and indicates no problem.
4a) A call to PQresultErrorMessage() indicates that the library knows the connection was administratively reset.
As a consumer of the API, not knowing (or wanting to know) what's going on under-the-hood, this looks like a bug; the library certainly did know that the connection can no longer be used or 4a wouldn't happen, but PQstatus() is not saying so. The documentation I see at http://www.postgresql.org/docs/9.0/interactive/libpq-status.html doesn't lead me to believe that any of this logic is faulty. That I have to iterate on step 2 above to get PQstatus() to eventually tell me the truth even though I know something has gone wrong already seems strange, and that's why I raised this issue.
Another possible explanation is that PQresultStatus() doesn't give a consistent result until after PQgetResult() has returned NULL. If that's the case, it should be documented, because right now it isn't.
-MSK
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-01-24 18:47:18 | Re: BUG #5837: PQstatus() fails to report lost connection |
Previous Message | Murray S. Kucherawy | 2011-01-24 18:04:14 | Re: BUG #5837: PQstatus() fails to report lost connection |