Re: "unexpected EOF" messages
От | Kevin Grittner |
---|---|
Тема | Re: "unexpected EOF" messages |
Дата | |
Msg-id | 4FA2771602000025000477F5@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: "unexpected EOF" messages (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: "unexpected EOF" messages
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: