| From: | Melvin Davidson <melvin6925(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | oleg yusim <olegyusim(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Session Identifiers |
| Date: | 2015-12-21 16:51:09 |
| Message-ID: | CANu8FixCrFKSWPJOoSVqpM+sj=SYObZeuAJh=kf7C1UD7LBPgA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Pursuant to Stehen's suggestion, I've attached a scripts that you can
execeute from a cron. I wrote it when I was working for a previous company
that used to have users that opened connections
and transaction that did nothing for a long time.
Just adjust the max_time for your liking. You can also add OR current_query
= '<IDLE>' to kill stagnant connections.
On Mon, Dec 21, 2015 at 11:42 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Oleg,
>
> * oleg yusim (olegyusim(at)gmail(dot)com) wrote:
> > tcp_keepalives_idle = 900
> > tcp_keepalives_interval=0
> > tcp_keepalives_count=0
> >
> > Doesn't terminate connection to database in 15 minutes of inactivity of
> > psql prompt. So, it looks like that would work only for case if network
> > connection is broken and session left hanging. For psql prompt case looks
> > like pg_terminate_backend() would be the only solution.
>
> Those settings aren't for controlling idle timeout of a connection.
>
> pg_terminate_backend() will work and could be run out of a cronjob.
>
> Thanks!
>
> Stephen
>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
| Attachment | Content-Type | Size |
|---|---|---|
| kill_long_idles.sh | application/x-sh | 1.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | oleg yusim | 2015-12-21 16:58:56 | Re: Session Identifiers |
| Previous Message | Stephen Frost | 2015-12-21 16:42:42 | Re: Session Identifiers |