> 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.)
Who owns the actual connections? [...] and now you’re saying connections aren’t assumed by the database.
Huh? What do you mean by "owns"? What does "connection's aren't assumed" mean? All Tom said is that PostgreSQL doesn't prevent a user from opening a connection and keeping it open indefinitely - at least so long as it isn't in a transaction.
Frankly, if you cannot explain how your client application is behaving you should overcome that knowledge gap first. You can probably infer some of that behavior from observing the server but a better approach is to read the documentation and/or code for the client library to see how it behaves - and then confirm that behavior by observing the server.
All that said there is a good chance Tom is right and there are network level issues going on here and that is a bit out of my league. I would suggest trying to create some kind of reproducible error via a standalone script and debug from that instead of observing a production server. Then you can run the script on a local-only setup to more confidently rule out application fault and rule in network fault.
