This introduces an acquisition timeout, making it possible to bail out of waiting for a connection cleanly. (Includes the changes from #16 to avoid dealing with conflicts, happy to rebase with only this change though if preferred.)
This times out only the "blocking for a slot" part of connection acquisition, not establishing the connection. (I think that's probably the cleaner approch, but it's a point to consider.)
Some alternative ideas of approaching this that wouldn't need changes to hasql-pool:
Just put a timeout on the whole action (i.e. timeout delay $ Pool.use $ query). Undesirable because it might mean interrupting while the query is running database server side, running into problems like returning a timeout error while postgres might still successfully apply the request.
A disarmable timeout (i.e. disarmableTimeout delay $ \disarm -> Pool.use $ disarm >> query). That should work, it's just tricky to get right and pretty complicated and I'd rather avoid going there. 😬
This introduces an acquisition timeout, making it possible to bail out of waiting for a connection cleanly. (Includes the changes from #16 to avoid dealing with conflicts, happy to rebase with only this change though if preferred.)
We want something like this for PostgREST (https://github.com/PostgREST/postgrest/issues/2348) to be able to actively time out queries that are blocked waiting for an overloaded connection pool.
hasql-pool
:timeout
on the whole action (i.e.timeout delay $ Pool.use $ query
). Undesirable because it might mean interrupting while the query is running database server side, running into problems like returning a timeout error while postgres might still successfully apply the request.disarmableTimeout delay $ \disarm -> Pool.use $ disarm >> query
). That should work, it's just tricky to get right and pretty complicated and I'd rather avoid going there. 😬