[pgpool-general: 6901] Pgpool postgresql - Idle connections close problem

Radosław Szczygieł radoslaw.szczygiel at interia.pl
Wed Mar 4 18:43:56 JST 2020

Hi Pgpool team,I have a strange problem with hanging connections in postgresql or I don't know something. On postgres in pg_stat_activity I see many idle connections with "query_start" and "state_change" time from the previous day but they should be closed after 500 seconds (pgpool.conf settings).I made a test: create simply python code with loop making connect (using psycopg2), insert and close connection.  Each code call creates a lot of postgres connections and does not close them. I understand that "connection cache" works, but according to pgpool documentation, if the same connection is used, using the same database, username and password should use the existing connection??Did I something misunderstand of connection pooling? Why these old connections in postgresql that are longer than the times specified in pgpool.conf not closed ??My cluster is : 2 pgpool 4.1 (watchdog) + 2 postgresql 12 (master slave replication)pgpool.conf# - Concurrent session and pool size -num_init_children = 300                                   # Number of concurrent sessions allowed                                   # (change requires restart)max_pool = 5                                   # Number of connection pool caches per connection                                   # (change requires restart)# - Life time -child_life_time = 600                # Pool exits after being idle for this many secondschild_max_connections = 1510                                   # Pool exits after receiving that many connections                                   # 0 means no exitconnection_life_time = 500                                   # Connection to backend closes after being idle for this many seconds                                   # 0 means no closeclient_idle_limit = 300                                   # Client is disconnected after being idle for that many seconds                                   # (even inside an explicit transactions!)                                   # 0 means no disconnectionRegardsRadoslaw Szczygiel--Pozdrawiam
Radosław Szczygieł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20200304/87c2a44c/attachment.html>

More information about the pgpool-general mailing list