Re: "unexpected EOF" messages

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Alvaro Herrera" <alvherre(at)commandprompt(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 17:16:21
Message-ID: 4FA2771602000025000477F5@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Well, nearby Tom and I discussed demoting the message to DEBUG1
>> when no transaction is in progress. Presumably the two messages
>> would share the same SQL state, unless we're going to create
>> separate SQL states for connection-closed-not-in-a-txn and
>> connection-closed-in-a-txn; and yet I think there's a very decent
>> argument that you're much more likely to care about the latter
>> than the former.
>
> If we're going to treat the two cases differently then assigning
> distinct SQLSTATEs seems entirely reasonable to me.

Would it make sense to use 08003 (connection_does_not_exist) when a
broken connection for an idle process is discovered, and 08006
(connection_failure) for the "in transaction" failure? What about a
failure just after COMMIT and before successfully sending that
result to the client? I notice there's a SQLSTATE 08007
(transaction_resolution_unknown), but I don't know whether that
makes sense on the server side, or just on the client side.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-03 17:20:41 Re: "unexpected EOF" messages
Previous Message Josh Berkus 2012-05-03 17:14:48 Re: Advisory locks seem rather broken