Open steve-chavez opened 4 months ago
Update on https://github.com/nikita-volkov/hasql-pool/issues/43, we now have https://github.com/nikita-volkov/hasql-pool/pull/45.
So with those new observations, we should be able to add two more metrics:
And then we can close this issue.
Environment
Problem
A running instance with a
db-pool = 60
reports the following problems.1. The authenticator role surpases db-pool connections.
Here it can be seen it reaches 71 connections.
At some other time it reports 130 connections and surpasses pg
max_connections
:2. PostgREST replies with an empty error message.
A subsequent request succeeds since PostgREST recovers though.
I wasn't able to find the root cause of this. This instance in particular just went through a migration from ipv4 to ipv6 only.
However it's clear that the hasql pool is not recycling the pool connections. An empty error message shouldn't happen too.
Proposal
We need to increase the pool log traces. Log whenever the hasql pool reaper works (ref). This way at least we can find out if the pool is misbehaving. Currently it's not possible to know if the reaper fails.
Workarounds
A connection limit can be set on the authenticator role so the
db-pool
max is guaranteed.An idle timeout can be set in case the pool doesn't recycle idle connections.
Related