Re: Connections Increasing Slowly

From: "Bee(dot)Lists" <bee(dot)lists(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Submit Postgresql Novice <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Connections Increasing Slowly
Date: 2020-06-23 01:57:44
Message-ID: 0345AEA7-346C-452F-B3AE-13ED57818F5F@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

> On Jun 22, 2020, at 4:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Postgres doesn't really think that killing connections is part of its
> charter. (There is idle_in_transaction_session_timeout, but that's
> there to guard against a specific performance issue, not to kill
> non-misbehaving sessions.)
>
> You should probably think about putting a connection pooler such as
> pgbouncer in front of your server. That's a better idea for lots of
> low-resource-demand clients than giving them direct server connections.
> And I think you're more likely to find features for killing idle
> connections there, too.
>
> Another idea, if you suspect that the idle connections are caused
> by firewall timeouts or the like, is to enable more aggressive
> TCP keepalive checking, to ensure the server notices if a client
> isn't there at all anymore. See the tcp_keepalives_* settings.
>
> regards, tom lane

Hi Tom.

Who owns the actual connections? The server allows them, the client requests them. The error I am getting is that the gem I’m using uses a connection that’s dropped. Actually I should say the “connection pool”. The client doesn’t (the gem author doesn’t elaborate on any of this), and now you’re saying connections aren’t assumed by the database.

It’s been recommended that pg_stat_statements and pg_stat_activity to see what’s happening.

Cheers, Bee

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Lane 2020-06-23 02:07:25 Re: Connections Increasing Slowly
Previous Message Tom Lane 2020-06-22 20:11:48 Re: Connections Increasing Slowly