You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pools now start with only 10 connections and create new ones up to tenant default_pool_size or user pool_size
Logs correct tenant id
API endpoints accept PATCH requests
Previously Supavisor would start a deterministic number of connection depending on the pool size specified on the tenant or tenant user.
Now Supavisor will start 10 connections and then allocate more as needed.
It was pretty easy to over-allocate your database max_connections without fully understanding what your max_connections were and how many were currently being used by other services.
This also makes migration from PgBouncer easier as it's much safer to run multiple connection poolers at the same time as you migrate, as long as they both don't need to allocate their full database connection pools.
Also an implied behavior of Supavisor was that each user connected spins up it's own pool. Without understanding this behavior it's easy to over-allocate database connections by connecting different Posgres users to the pooler.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Released Supavisor 1.1.5
Notable
Previously Supavisor would start a deterministic number of connection depending on the pool size specified on the tenant or tenant user.
Now Supavisor will start 10 connections and then allocate more as needed.
It was pretty easy to over-allocate your database max_connections without fully understanding what your max_connections were and how many were currently being used by other services.
This also makes migration from PgBouncer easier as it's much safer to run multiple connection poolers at the same time as you migrate, as long as they both don't need to allocate their full database connection pools.
Also an implied behavior of Supavisor was that each user connected spins up it's own pool. Without understanding this behavior it's easy to over-allocate database connections by connecting different Posgres users to the pooler.
Beta Was this translation helpful? Give feedback.
All reactions