| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Li Japin <japinli(at)hotmail(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Terminate the idle sessions |
| Date: | 2020-06-09 14:35:08 |
| Message-ID: | CAKFQuwanQpVPbdzQB1nGZzi82_5HB2uWteWB9cTy1HLhOMsiKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday, June 9, 2020, Li Japin <japinli(at)hotmail(dot)com> wrote:
> Hi, hackers
>
> When some clients connect to database in idle state, postgres do not close
> the idle sessions,
> here i add a new GUC idle_session_timeout to let postgres close the idle
> sessions, it samilar
> to idle_in_transaction_session_timeout
>
I’m curious as to the use case because I cannot imagine using this. Idle
connections are normal. Seems better to monitor them and conditionally
execute the disconnect backend function from the monitoring layer than
indiscriminately disconnect based upon time. Though i do see an
interesting case for attaching to specific login user accounts that only
manually login and want the equivalent of a timed screen lock.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2020-06-09 15:10:22 | Re: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events |
| Previous Message | Ranier Vilela | 2020-06-09 14:31:35 | Re: Speedup usages of pg_*toa() functions |