Sort out postgresql pool mess
Closed this issue · 1 comments
pnorman commented
Currently Storage takes a pool and the dev/live servers give it a connection pool of size 1. This is a bit silly, since connections could be handed in instead. There's a few options, which should be considered after the parallelism work is done
- continue as-is because it might turn out Storage needs to take a pool for parallelism reasons later on
- change Storage to take a connection
I don't see an obvious way to have variables that are global between multiple serving processes, so having a pool of a size > 1 won't work with uvicorn
pnorman commented
Something to consider is how to handle terminated connections and check that any options will do that