Idle PostgreSQL connections leak, leading to connection exhaustion

Describe the bug
TubeSync continuously opens and accumulates persistent idle database connections in PostgreSQL over time. Even when frontend worker configurations (like Gunicorn workers) are restricted, background tasks or worker threads appear to spawn and orphan database sockets without properly closing or recycling them. Eventually, this exhausts PostgreSQL's max_connections limit, resulting in connection refusal errors across services sharing the same database cluster:
53300: remaining connection slots are reserved for roles with the SUPERUSER attribute

To Reproduce
Steps to reproduce the behavior:

Deploy TubeSync using PostgreSQL as the backend database.
Let the container run normal background feed polling and synchronization tasks over a few minutes.
Check active database connections on the PostgreSQL server (e.g., via pg_stat_activity).
Observe a growing, un-reaped accumulation of tubesync connections sitting in an idle state.

Expected behavior
TubeSync workers should properly check out, utilize, and return/close database connections to the pool when tasks complete, maintaining a stable and conservative connection footprint without leaking sockets.

Logs / Screenshots
PostgreSQL process list snippet showing the accumulation of idle connections:

postgres: 17/main: tubesync tubesync 192.168.11.67(34192) idle
postgres: 17/main: tubesync tubesync 192.168.11.67(34194) idle
postgres: 17/main: tubesync tubesync 192.168.11.67(34220) idle
... (dozens of lingering idle connections)

Environment:

TubeSync Version: latest
Deployment Method: Docker container
Database: PostgreSQL 17

I haven't actually seen any evidence of leaked connections.

There are quite a few processes now and each is going to maintain its own pool.

This can be adjusted in common/utils.py around line 191.
You can change min_size to zero so that no idle connections are maintained, but I would not recommend that.

tubesync/tubesync/common/utils.py

Lines 188 to 198 in 8feb0cd

    
           backend_options = { 
        
               'postgresql': dict(pool={ 
        
                   'max_size': 10, # default: None (static min_size pool) 
        
                   'min_size': 3, # default: 4 
        
                   'num_workers': 2, # default: 3 
        
                   'timeout': 180, # default: 30 
        
               }), 
        
               'mysql': { 
        
                   'charset': 'utf8mb4', 
        
               } 
        
           }

Watch idle connections

SELECT pid, client_addr, client_port, backend_start, query_start, state_change
FROM pg_stat_activity
WHERE datname = 'tubesync'
AND state = 'idle'
AND wait_event = 'ClientRead'
AND state_change < now() - interval '10 minutes'
ORDER BY 4, 2, 3 \watch i=20 c=3

Mitigation

tubesync=# ALTER SYSTEM SET idle_session_timeout = "1h";
ALTER SYSTEM
tubesync=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

tubesync=# SHOW idle_session_timeout;
 idle_session_timeout
----------------------
 1h
(1 row)

tubesync=#

I've tracked down a fork / thread interaction that leaves the child process (the task execution worker) with a pool that has no threads to service the connections.

I'll try to get changes tested and merged into main before the next release.

Navigation Menu

Repository navigation

Idle PostgreSQL connections leak, leading to connection exhaustion #1632

Watch idle connections

Related

Mitigation

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	backend_options = {
	'postgresql': dict(pool={
	'max_size': 10, # default: None (static min_size pool)
	'min_size': 3, # default: 4
	'num_workers': 2, # default: 3
	'timeout': 180, # default: 30
	}),
	'mysql': {
	'charset': 'utf8mb4',
	}
	}

Idle PostgreSQL connections leak, leading to connection exhaustion #1632

Description

Activity

tcely commented on Nov 2, 2026

Watch idle connections

Related

Mitigation

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions