> On Jun 22, 2020, at 4:11 PM, Tom Lane <tgl@sss.pgh.pa.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
gemI’m using uses a connection that’s dropped. Actually I should say the “connection pool”. The client doesn’t (the
gemauthor 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
