| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: "unexpected EOF" messages |
| Date: | 2012-05-03 18:25:51 |
| Message-ID: | 11614.1336069551@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> I still think it might be useful to differentiate in our server log
> between the case where the transaction failed and the case where the
> transaction committed but we don't know that the client got the news
> of that. How about something like:
> 2DP01 connection_lost_during_transaction
> 2DP02 connection_lost_during_commit_notification
That would be a useful distinction, but I'm not sure how easily our
code can make it.
> I'm less sure what makes sense if the connection fails while idle
> (not in transaction). If you don't like "Class 08 * Connection
> Exception" for that, I'm not quite sure where it belongs.
I'm not convinced that these cases belong in any of the standard's
classes. IMO the standard is only standardizing application-visible
error cases, which these are not. In particular I think class 2D is
not appropriate, since AFAICS the standard means that to pertain to
incorrect issuance of a COMMIT or ROLLBACK command.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-05-03 18:50:30 | Re: CLOG extension |
| Previous Message | Andres Freund | 2012-05-03 18:19:42 | Re: Advisory locks seem rather broken |