Re: pg_cancel_backend and pg_terminate_backend

Поиск
Список
Период
Сортировка
От Rui DeSousa
Тема Re: pg_cancel_backend and pg_terminate_backend
Дата
Msg-id FBABAD0E-4E87-4A6B-A39A-7EB4E9E26979@crazybean.net
обсуждение исходный текст
Ответ на Re: pg_cancel_backend and pg_terminate_backend  (Rui DeSousa <rui@crazybean.net>)
Список pgsql-admin


On Apr 19, 2023, at 8:37 PM, Rui DeSousa <rui@crazybean.net> wrote:



On Apr 19, 2023, at 3:51 PM, Wetmore, Matthew (CTR) <Matthew.Wetmore@express-scripts.com> wrote:

I usually prefer pg_cancel_backend because it seems.. nicer, but lately I've had a troublesome user who leaves transactions open and I've scripted up a call to pg_terminate_backend after 60 minutes in an idle transaction. It works well.
 
Question: is there any server impact beyond that user's transaction when calling pg_terminate_backend? 

I would advise against doing that for application connections.  What happens depends on the application or pooling tech used.  It could generate errors in the application as the connection is no longer valid yet the application might still being maintaining data structures for the given connection.  

I.e.. It also introduces a race condition; the application picks up the connection from the connection pool at the same time the connection is terminated on the backend; the end result is an error propagating up to end user or the application being require to catch the error and retry, etc. 

I would continue to terminate non application connections without concern.  If it’s an issue, fix the application/pooling config; terminating backend sessions is a bandaid with other issues.

One more thought if it wasn’t apparent already.  Use TCP keep alive -- to identify truly abandoned idle sessions and have those connection torn down.

В списке pgsql-admin по дате отправления:

Предыдущее
От: Rui DeSousa
Дата:
Сообщение: Re: pg_cancel_backend and pg_terminate_backend
Следующее
От: John Scalia
Дата:
Сообщение: Re: PgAdmin cannot locate my server