Re: idle_in_transaction_timeout
От | Vik Fearing |
---|---|
Тема | Re: idle_in_transaction_timeout |
Дата | |
Msg-id | 538E600E.1020708@dalibo.com обсуждение исходный текст |
Ответ на | Re: idle_in_transaction_timeout (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On 06/04/2014 01:38 AM, Josh Berkus wrote: > On 06/03/2014 02:53 PM, Tom Lane wrote: >> Josh Berkus <josh@agliodbs.com> writes: >>> Out of curiosity, how much harder would it have been just to abort the >>> transaction? I think breaking the connection is probably the right >>> behavior, but before folks start arguing it out, I wanted to know if >>> aborting the transaction is even a reasonable thing to do. >> FWIW, I think aborting the transaction is probably better, especially >> if the patch is designed to do nothing to already-aborted transactions. >> If the client is still there, it will see the abort as a failure in its >> next query, which is less likely to confuse it completely than a >> connection loss. (I think, anyway.) > Personally, I think we'll get about equal amounts of confusion either way. > >> The argument that we might want to close the connection to free up >> connection slots doesn't seem to me to hold water as long as we allow >> a client that *isn't* inside a transaction to sit on an idle connection >> forever. Perhaps there is room for a second timeout that limits how >> long you can sit idle independently of being in a transaction, but that >> isn't this patch. > Like I said, I'm marginally in favor of terminating the connection, but > I'd be completely satisfied with a timeout which aborted the transaction > instead. Assuming that change doesn't derail this patch and keep it > from getting into 9.5, of course. The change is as simple as changing the ereport from FATAL to ERROR. Attached is a new patch doing it that way. -- Vik
Вложения
В списке pgsql-hackers по дате отправления: