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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Advisory locks seem rather broken
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "unexpected EOF" messages