mirror of
https://github.com/block/buzz.git
synced 2026-08-18 06:50:31 +02:00
npub17jjz49l9jjmhhk7cac63j8yt9z555n9cw8vk7v5jz4vzw4ppld5qgj57cc
b380ba3e07
The relay could size the pool ceiling via BUZZ_DB_POOL_SIZE but had no way to set the floor: DbConfig::min_connections existed and was applied, yet the only value it ever took in production was the hardcoded 2 from DbConfig::default(), because relay main filled the rest of the struct from that default. Add BUZZ_DB_MIN_POOL_SIZE -> Config::db_pool_min_size (default 20) and wire it into the writer pool explicitly, mirroring how the maximum is already plumbed. The default lives at the relay env boundary rather than in DbConfig::default() on purpose. buzz-admin also constructs DbConfig with ..DbConfig::default() and is a short-lived CLI that connects, performs one operation and exits, so raising the library default would make every admin invocation eagerly open 20 sessions for no throughput benefit. The value is clamped to db_pool_size. sqlx obeys max_connections regardless (try_min_connections bails when the semaphore has no permit) so an unclamped pair is not a hang, but sqlx stores the requested minimum verbatim and documents that applications allowing either value to be set dynamically should validate the pair themselves. Without the clamp, pool.options() would report an impossible min > max. Unlike the pool maxima, 0 is honoured rather than rejected: a minimum of zero is a meaningful setting (a fully lazy pool, which is what the read-replica pool pins deliberately), whereas a maximum of zero is not. Reusing the maxima's filter(v > 0) would make the one value an operator would reach for to stop pre-warming silently mean 20 instead. The reader pool is untouched: it stays pinned at 0 and lazy so a replica that is down at boot cannot gate relay startup. Co-authored-by: npub17jjz49l9jjmhhk7cac63j8yt9z555n9cw8vk7v5jz4vzw4ppld5qgj57cc <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz> Signed-off-by: npub17jjz49l9jjmhhk7cac63j8yt9z555n9cw8vk7v5jz4vzw4ppld5qgj57cc <f4a42a97e594b77bdbd8ee35191c8b28a94a4cb871d96f32921558275421fb68@buzz.block.builderlab.xyz>