![]() ![]() it is expensive to establish a database connection.If your HTTP connection is broken, you simply establish a new connection for your next request, which isn’t very expensive. Since a lot of today’s TCP traffic is via HTTP, and HTTP is stateless, that’s not normally a problem. So it can seem expedient to “forget” and drop connections that have been idle for a longer time. The network component may have to “memorize” the state of each open connection, and the resources for that are limited. But very often, disconnections are caused by the way firewalls or routers are configured. There’s nothing you can do to change that on the software level. Network connections can get disconnected if there is a real connectivity problem. In that case, the problem lies somewhere between the database client and the server. Sometimes both ends of the database connection experience the same problem: each sees that the other end “hung up on them”. Connections closed by a network component TCP keepalive provides a much better solution to this problem. But that will terminate “healthy” idle connections as well, so it isn’t a very good solution. PostgreSQL v14 has introduced a new parameter idle_session_timeout which closes idle connections after a while. Then the server won’t immediately notice that the client is no longer there! Such lingering backend processes occupy a process slot and can cause you to exceed max_connections. But if the database session is idle, the server process is waiting for the client to send the next statement (you can see the wait_event “ ClientRead” in pg_stat_activity). This isn’t alarming, and the database server will quickly detect it when the server tries to send data to the client. With the new session statistics introduced in v14, you can track the number of such “abandoned” database connections in pg_stat_ssions_abandoned.įor example, if an application server fails and is restarted, it typically won’t close the connections to the database server. If the client exits without properly closing the database connection, the server will get an end-of-file or an error while communicating on the network socket. We won’t deal with that case in the following, since it isn’t a network problem. To investigate whether there is a server problem, you should first look into the PostgreSQL log and see if you can find a matching crash report. ![]() If the server crashes for whatever reason, you’ll see a message like that. The first two messages in the above list can be the consequence of a PostgreSQL server problem. There are several possible causes for broken connections: Database server crashes could not receive data from client: Connection reset by peer.server closed the connection unexpectedly.If you’ve ever been surprised by error messages like: (Updated ) If you’ve heard about TCP keepalive but aren’t sure what that is, read on. ![]() Connection idle keepalive network postgresql ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |