Skip to content

Postgres connections can exhaust the tokio blocking pool and starve the native listener #60

Description

@martian56

Each Postgres wire connection holds a blocking pool thread for its whole lifetime (server/src/pg.rs:67 spawns once per connection and loops inside). The admission semaphore is sized from QUANTA_MAX_CONNECTIONS, which defaults to 1024 (server/src/config.rs), but tokio's default max_blocking_threads is 512.

Past 512 concurrent pg connections the semaphore admits clients that then queue in the blocking pool and never run. Worse, the native listener calls spawn_blocking per request against the same pool, so a saturated pg listener stalls native clients too.

Either cap pg admission at the blocking pool size, raise max_blocking_threads to match max_connections, or move pg connections onto their own runtime or dedicated threads. Not reachable at benchmark concurrency, but it is a real ceiling.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions